From daemon@optimus.ietf.org  Wed May  1 01:30:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22439
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 01:30:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA28158
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 01:30:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19095;
	Wed, 1 May 2002 01:04:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA19065
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 01:04:13 -0400 (EDT)
Received: from nghmail ([63.104.239.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22099
	for <sip@ietf.org>; Wed, 1 May 2002 01:04:11 -0400 (EDT)
Received: (qmail 13009 invoked from network); 1 May 2002 06:05:21 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.4)
  by nghmail with SMTP; 1 May 2002 06:05:21 -0000
Message-ID: <003201c1f0ce$362c80e0$5601a8c0@knowsys.net>
From: "vishal" <vishal@knowsys.net>
To: <sip@ietf.org>
Cc: <sip-implementors@cs.columbia.edu>
Date: Wed, 1 May 2002 10:38:08 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002F_01C1F0FC.48C0BC20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [Sip] capability exchange in SIP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C1F0FC.48C0BC20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi ,
   I have following questions=20

1. Does SIP provides capabiltiy to choose different codecs available at =
endpoints  =20
    for call?

2. How can bandwidth be controlled by external entity for SIP based call =
?=20

regards, vishal






------=_NextPart_000_002F_01C1F0FC.48C0BC20
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi ,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; I have following questions =

</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>1. Does SIP provides capabiltiy to =
choose different=20
codecs available at endpoints&nbsp;&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; for =
call?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>2. How can bandwidth be controlled by =
external=20
entity for SIP based call ? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>regards, vishal</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_002F_01C1F0FC.48C0BC20--


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



From daemon@optimus.ietf.org  Wed May  1 02:47:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15790
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 02:47:13 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA14682
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 02:47:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00237;
	Wed, 1 May 2002 02:13:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00208
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 02:12:57 -0400 (EDT)
Received: from nghmail ([63.104.239.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01227
	for <sip@ietf.org>; Wed, 1 May 2002 02:12:54 -0400 (EDT)
Received: (qmail 22301 invoked from network); 1 May 2002 07:14:03 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.4)
  by nghmail with SMTP; 1 May 2002 07:14:03 -0000
Message-ID: <005801c1f0d7$cf2aad40$5601a8c0@knowsys.net>
From: "vishal" <vishal@knowsys.net>
To: <sip@ietf.org>
Date: Wed, 1 May 2002 11:46:55 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0055_01C1F105.E46F1460"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [Sip] request/response over different transport
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0055_01C1F105.E46F1460
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi ,
      It should be possible to receive request sent over UDP and send =
response over TCP because in some cases when UDP message size is greater =
than MTU size ,then message sending will not succeed .
        Reverse of this should not be allowed i.e receive over TCP and =
send response over UDP .

Possible scenario can be  endpoint received  query for cappability set =
over UDP but response message is  bigger than MTU size ...

regards, vishal=20















       =20


------=_NextPart_000_0055_01C1F105.E46F1460
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi ,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It =
should be=20
possible to receive request sent over UDP and send response over TCP =
because in=20
some cases when UDP message size is greater than MTU size ,then message =
sending=20
will not succeed .</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reverse=20
of this should not be allowed&nbsp;i.e receive over TCP and send =
response over=20
UDP .</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Possible scenario can be&nbsp; endpoint =

received&nbsp; query for cappability set&nbsp;over UDP but response =
message=20
is&nbsp; bigger than MTU size ...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>regards, vishal </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0055_01C1F105.E46F1460--


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



From daemon@optimus.ietf.org  Wed May  1 03:19:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01463
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 03:19:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA16071
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 03:19:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14849;
	Wed, 1 May 2002 02:53:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA14818
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 02:53:45 -0400 (EDT)
Received: from obsoft.com (sdsl-64-139-4-113.dsl.sca.megapath.net [64.139.4.113])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15877
	for <sip@ietf.org>; Wed, 1 May 2002 02:53:42 -0400 (EDT)
Received: from obsoft.com (localhost.localdomain [127.0.0.1])
	by obsoft.com (8.11.6/8.11.6) with ESMTP id g416wIt25999;
	Tue, 30 Apr 2002 23:58:18 -0700
Message-ID: <3CCF9209.50FDA3B1@obsoft.com>
Date: Tue, 30 Apr 2002 23:58:17 -0700
From: Bobby Sardana <sardana@obsoft.com>
Organization: ObjectSoftware, Inc
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: vishal <vishal@knowsys.net>
CC: sip@ietf.org
Subject: Re: [Sip] request/response over different transport
References: <005801c1f0d7$cf2aad40$5601a8c0@knowsys.net>
Content-Type: multipart/alternative;
 boundary="------------EAA71B19208A54ED52F31A71"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


--------------EAA71B19208A54ED52F31A71
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The scenario you have described requires the UAS to decide whether to
transport via TCP or UDP, depending on the request and the response. If
the response size is less than path MTU then I am not sure why can't we
use UDP for response.

regards,

Bobby Sardana.
sardana@obsoft.com

vishal wrote:

> Hi ,      It should be possible to receive request sent over UDP and
> send response over TCP because in some cases when UDP message size is
> greater than MTU size ,then message sending will not succeed .
> Reverse of this should not be allowed i.e receive over TCP and send
> response over UDP . Possible scenario can be  endpoint received  query
> for cappability set over UDP but response message is  bigger than MTU
> size ...
>   regards, vishal

--------------EAA71B19208A54ED52F31A71
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
The scenario you have described requires the UAS to decide whether to transport
via TCP or UDP, depending on the request and the response. If the response
size is less than path MTU then I am not sure why can't we use UDP for
response.
<p>regards,
<p>Bobby Sardana.
<br>sardana@obsoft.com
<p>vishal wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>Hi
,</font></font><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
It should be possible to receive request sent over UDP and send response
over TCP because in some cases when UDP message size is greater than MTU
size ,then message sending will not succeed .</font></font><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Reverse of this should not be allowed i.e receive over TCP and send response
over UDP .</font></font>&nbsp;<font face="Arial"><font size=-1>Possible
scenario can be&nbsp; endpoint received&nbsp; query for cappability set
over UDP but response message is&nbsp; bigger than MTU size ...</font></font>
<br><font face="Arial"><font size=-1></font></font>&nbsp;&nbsp;<font face="Arial"><font size=-1>regards,
vishal</font></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</blockquote>

</body>
</html>

--------------EAA71B19208A54ED52F31A71--


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



From daemon@optimus.ietf.org  Wed May  1 03:57:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04483
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 03:57:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA17740
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 03:57:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16523;
	Wed, 1 May 2002 03:30:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16465
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 03:30:14 -0400 (EDT)
Received: from nghmail ([63.104.239.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02432
	for <sip@ietf.org>; Wed, 1 May 2002 03:30:11 -0400 (EDT)
Received: (qmail 1397 invoked from network); 1 May 2002 08:31:22 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.4)
  by nghmail with SMTP; 1 May 2002 08:31:22 -0000
Message-ID: <009c01c1f0e2$9c0912c0$5601a8c0@knowsys.net>
From: "vishal" <vishal@knowsys.net>
To: "Bobby Sardana" <sardana@obsoft.com>
Cc: <sip@ietf.org>
References: <005801c1f0d7$cf2aad40$5601a8c0@knowsys.net> <3CCF9209.50FDA3B1@obsoft.com>
Subject: Re: [Sip] request/response over different transport
Date: Wed, 1 May 2002 13:04:14 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0099_01C1F110.B1C2F800"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0099_01C1F110.B1C2F800
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Bobby,
      you are correct if message size is less than MTU size then =
response must be over UDP .....

some other problems are :

 when proxy forwards INVITE requests .It adds "Via:" field into it along =
with appropriate parametres ....if message is forwarded by many proxies =
then this message may become greater than MTU size in particular network =
....how this  case should be handled ?=20
    should next proxy establish TCP connection and then forward it OR =
reject this message?

If proxy forwards this  message using TCP and UAS receives INVITE over =
TCP then UAS  response will be sent over TCP  and UAC should be prepared =
to receive response over TCP or UDP  for its previous INVITE over UDP =
request.

regards, vishal

Vishal ,
Knowledge Systems Pvt Ltd  ,INDIA
470, East End Main Road =20
9th Block Jayanagar=20
Bangalore
     =20
  ----- Original Message -----=20
  From: Bobby Sardana=20
  To: vishal=20
  Cc: sip@ietf.org=20
  Sent: Wednesday, May 01, 2002 12:28 PM
  Subject: Re: [Sip] request/response over different transport


  The scenario you have described requires the UAS to decide whether to =
transport via TCP or UDP, depending on the request and the response. If =
the response size is less than path MTU then I am not sure why can't we =
use UDP for response.=20
  regards,=20

  Bobby Sardana.=20
  sardana@obsoft.com=20

  vishal wrote:=20

    Hi ,      It should be possible to receive request sent over UDP and =
send response over TCP because in some cases when UDP message size is =
greater than MTU size ,then message sending will not succeed .        =
Reverse of this should not be allowed i.e receive over TCP and send =
response over UDP . Possible scenario can be  endpoint received  query =
for cappability set over UDP but response message is  bigger than MTU =
size ...=20
      regards, vishal                =20

------=_NextPart_000_0099_01C1F110.B1C2F800
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Bobby,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;you =
are correct=20
if message size is less than MTU size then response&nbsp;must be =
over&nbsp;UDP=20
.....</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>some other problems are :</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;when proxy forwards INVITE =
requests .It adds=20
"Via:" field into it along with appropriate&nbsp;parametres ....if =
message is=20
forwarded by many proxies then this message may become greater than MTU =
size in=20
particular network ....how this&nbsp; case should be handled ? =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; should next proxy =
establish TCP=20
connection and then forward it&nbsp;OR reject this message?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>If proxy forwards this  message using =
TCP and UAS=20
receives INVITE over TCP then UAS  response will be sent over TCP&nbsp; =
and UAC=20
should be prepared to receive response over TCP or UDP&nbsp; for its =
previous=20
INVITE over UDP request.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>regards, vishal</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#808080 face=3DArial size=3D2>Vishal ,<BR>Knowledge =
Systems Pvt=20
Ltd&nbsp; ,INDIA<BR>470, East End Main Road&nbsp; <BR>9th Block =
Jayanagar=20
</FONT></DIV>
<DIV><FONT color=3D#808080 face=3DArial size=3D2>Bangalore</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-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 href=3D"mailto:sardana@obsoft.com" title=3Dsardana@obsoft.com>Bobby =
Sardana</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:vishal@knowsys.net"=20
  title=3Dvishal@knowsys.net>vishal</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:sip@ietf.org"=20
  title=3Dsip@ietf.org>sip@ietf.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, May 01, 2002 =
12:28=20
  PM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [Sip] =
request/response over=20
  different transport</DIV>
  <DIV><BR></DIV>The scenario you have described requires the UAS to =
decide=20
  whether to transport via TCP or UDP, depending on the request and the=20
  response. If the response size is less than path MTU then I am not =
sure why=20
  can't we use UDP for response.=20
  <P>regards,=20
  <P>Bobby Sardana. <BR><A=20
  href=3D"mailto:sardana@obsoft.com">sardana@obsoft.com</A>=20
  <P>vishal wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">
    <STYLE></STYLE>
    <FONT face=3DArial><FONT size=3D-1>Hi ,</FONT></FONT><FONT =
face=3DArial><FONT=20
    size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It should be possible to =
receive=20
    request sent over UDP and send response over TCP because in some =
cases when=20
    UDP message size is greater than MTU size ,then message sending will =
not=20
    succeed .</FONT></FONT><FONT face=3DArial><FONT=20
    size=3D-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reverse of this =
should=20
    not be allowed i.e receive over TCP and send response over UDP=20
    .</FONT></FONT>&nbsp;<FONT face=3DArial><FONT size=3D-1>Possible =
scenario can=20
    be&nbsp; endpoint received&nbsp; query for cappability set over UDP =
but=20
    response message is&nbsp; bigger than MTU size ...</FONT></FONT> =
<BR><FONT=20
    face=3DArial><FONT size=3D-1></FONT></FONT>&nbsp;&nbsp;<FONT =
face=3DArial><FONT=20
    size=3D-1>regards,=20
    =
vishal</FONT></FONT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</BLOCKQUOTE></BLOCKQUOT=
E></BODY></HTML>

------=_NextPart_000_0099_01C1F110.B1C2F800--


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



From daemon@optimus.ietf.org  Wed May  1 07:46:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22238
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 07:46:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA02644
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 07:46:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24891;
	Wed, 1 May 2002 07:26:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24689
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 07:25:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20103;
	Wed, 1 May 2002 07:25:40 -0400 (EDT)
Message-Id: <200205011125.HAA20103@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 01 May 2002 07:25:39 -0400
Subject: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private SIP Extension for Original Dialog Identifier
	Author(s)	: E. Henrikson
	Filename	: draft-henrikson-sip-original-dialog-id-00.txt
	Pages		: 7
	Date		: 30-Apr-02
	
This document proposes a private SIP extension header used in 
conjunction with INVITE requests to provide a mechanism by which a 
stateful proxy may associate an INVITE request processed earlier 
with the INVITE request that is being currently processed. The 
association is needed by the Serving Call Session Control Function 
(S-CSCF) from the Third Generation Partnership Project (3GPP) 
architecture to ensure proper routing of an INVITE request with 
3GPP Application Servers (AS). A S-CSCF may route an INVITE request 
to multiple AS, as indicated by a subscriber profile, and each AS 
may be a B2BUA. The S-CSCF needs to keep track of each AS contacted 
and know that an incoming INVITE request is related to a previous 
outgoing INVITE request such that each AS may receive the INVITE 
request before it is sent on towards the intended destination. When 
a B2BUA AS is  involved, there is currently not a way to associate 
the incoming INVITE request with the previously sent INVITE request 
at the S-CSCF. The P-Original-Dialog-ID header provides a way to 
accomplish this association. The same mechanism may be applied to 
any SIP method that is used to initiate a dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt

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

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

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


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

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

--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:	<20020430135712.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-henrikson-sip-original-dialog-id-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May  1 07:56:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23361
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 07:56:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA08625
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 07:56:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24701;
	Wed, 1 May 2002 07:25:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24587
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 07:25:37 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20039;
	Wed, 1 May 2002 07:25:33 -0400 (EDT)
Message-Id: <200205011125.HAA20039@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 01 May 2002 07:25:33 -0400
Subject: [Sip] I-D ACTION:draft-henrikson-sip-charging-information-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private SIP Extension for Mobile Charging Information
	Author(s)	: E. Henrikson
	Filename	: draft-henrikson-sip-charging-information-00.txt
	Pages		: 6
	Date		: 30-Apr-02
	
This document proposes a private SIP extension header P-Charging-
Function-Addresses used to pass the addresses of entities that 
provide a charging function. There is a need in the Third 
Generation Partnership Project (3GPP) for entities that process 
charging information. For a particular dialog or standalone 
transaction, a proxy (or UA within the network, e.g. a gateway) may 
need to pass information to one or more charging entities. The 
affected UAs and proxies associated with the dialog or standalone 
transaction need to know the identities or addresses of the 
appropriate charging entities.  
This document also proposes a private SIP extension header P-
Charging-Vector to pass correlation information for charging 
purposes. The network entities in the 3GPP architecture share 
correlation information to ensure that charging activities are 
coordinated.  The need applies for any SIP method used to initiate 
a dialog, standalone messages and some response messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-information-00.txt

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

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

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


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

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

--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:	<20020430135701.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-henrikson-sip-charging-information-00.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May  1 08:10:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23855
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 08:10:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA09578
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 08:10:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02444;
	Wed, 1 May 2002 07:45:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA20195
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 04:58:06 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09788
	for <sip@ietf.org>; Wed, 1 May 2002 04:58:04 -0400 (EDT)
Received: from jku2.dynamicsoft.com (port-213-20-228-162.reverse.qdsl-home.de [213.20.228.162])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g418xaK00442;
	Wed, 1 May 2002 10:59:37 +0200
Message-Id: <5.1.0.14.0.20020501104513.0178da88@iptel.org>
X-Sender: jiri@iptel.org (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 May 2002 10:57:10 +0200
To: "Dean Willis" <dean.willis@softarmor.com>,
        "'chen Zhang'" <c_zhang88@hotmail.com>, <sip@ietf.org>
From: Jiri Kuthan <jkuthan@dynamicsoft.com>
Subject: RE: [Sip] SIP and MPLS
In-Reply-To: <028101c1f091$10af90b0$1c2e713f@TXDWILLIS2>
References: <F191irbThA9QRmzeyNt00003d26@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

There was a VoMPLS BoF in IETF 47th (adelaide), 
http://www.ietf.org/proceedings/00mar/47th-ietf-00mar-152.html#TopOfPage
Its advocates had hard time to explain why shall we not
have FTPoMPLS as well. There was little willingness to commit
layer violation (e.a., teach apps L2).

If whoever is interested in implementing foo-over-MPLS, I can
wholeheartly recommend RFC3251, which provides an excellent
template.

-Jiri

At 11:50 PM 4/30/2002, Dean Willis wrote:

>I believe Jon Crowcroft and Mark Gibson suggested something like this at
>IETF 46 and barely escaped afterwards. So it's definitely a possibility.
>However, it didn't appear at the time that there was much interest in
>pursuing it at the IETF.
>
>The slides from their presentation should be at:
>
>http://www.softarmor.com/sipwg/meets/ietf46/slides/pres-gibson-sip-qos-r
>esv-sip-46.PDF
>
>And the related draft is probably still in the draft "morgue" on that
>site.
>
>--
>Dean Willis
>
>
>> -----Original Message-----
>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
>> Behalf Of chen Zhang
>> Sent: Tuesday, April 30, 2002 11:05 AM
>> To: sip@ietf.org
>> Subject: [Sip] SIP and MPLS
>> 
>> 
>> Hi,
>> SIP is an application layer protocol and origins as a large 
>> scale multiparty 
>> conferencing protocol.
>> MPLS is an advanced forwarding scheme.
>> 
>> Is it possible to join the SIP and MPLS? If it is, we can get 
>> following benefits: 1. using SIP to set up the LSP. 2. 
>> providing the higher quality in the Internet.
>> 
>> IF you have any comments about that, Please let me know.
>> 
>> Thank you for your attention
>> 
>> Best regards
>> 
>> Chen
>> 
>> 
>> 
>> _________________________________________________________________
>> Send and receive Hotmail on your mobile device: http://mobile.msn.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



From daemon@optimus.ietf.org  Wed May  1 10:07:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28534
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 10:07:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA16117
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 10:07:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14236;
	Wed, 1 May 2002 09:39:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14169
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 09:38:59 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26940
	for <sip@ietf.org>; Wed, 1 May 2002 09:38:57 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g41Dc0d25867;
	Wed, 1 May 2002 08:38:00 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <jo@ipdialog.com>, <brian.rosen@marconi.com>, <Rohan@cicso.com>,
        "'Allison Mankin'" <mankin@isi.edu>, "Keith Drage" <drage@lucent.com>,
        "Henrikson, Eric H \(Eric\)" <ehenrikson@lucent.com>
Date: Wed, 1 May 2002 08:37:37 -0500
Message-ID: <000001c1f115$5df30760$1c2e713f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <200205011125.HAA20103@ietf.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


The SIP working group has been asked to provide expert review of
draft-henrikson-sip-original-dialog-id. This documents a P-header used
in 3GPP to associate dialogs across a 3GPP application server acting as
a back-to-back user agent.

We'd like to complete expert review by May 10, 2002.

Please copy your comments to the list and to Keith Drage and Eric
Henrikson, who will coordinate responses and edit the draft
apporpriately.

Thanks,

--
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 daemon@optimus.ietf.org  Wed May  1 10:08:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28574
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 10:08:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA16145
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 10:08:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14206;
	Wed, 1 May 2002 09:39:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14161
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 09:38:57 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26938
	for <sip@ietf.org>; Wed, 1 May 2002 09:38:54 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g41Dc3d25872;
	Wed, 1 May 2002 08:38:03 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <Rohan@cicso.com>, "'Allison Mankin'" <mankin@isi.edu>, <jo@ipdialog.com>,
        <brian.rosen@marconi.com>, "Keith Drage" <drage@lucent.com>,
        "Henrikson, Eric H \(Eric\)" <ehenrikson@lucent.com>
Date: Wed, 1 May 2002 08:37:37 -0500
Message-ID: <000101c1f115$5eb9b2c0$1c2e713f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <200205011125.HAA20039@ietf.org>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Expert Review: draft-henrikson-sip-charging-information-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


The SIP Working Group has been requested to provide expert review of
draft-henrikson-sip-charging-information. This draft documents P-headers
used to interact with the accounting system in 3GPP.

We'd like to complete review by May 10, 2002.


http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-informa
tion-00.txt


Thanks!

--
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 daemon@optimus.ietf.org  Wed May  1 11:46:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04415
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 11:46:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA22177
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 11:46:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16534;
	Wed, 1 May 2002 10:17:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA15100
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 09:57:20 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27828;
	Wed, 1 May 2002 09:57:18 -0400 (EDT)
Message-Id: <200205011357.JAA27828@ietf.org>
To: IETF-Announce: ;
Cc: sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Wed, 01 May 2002 09:57:18 -0400
Subject: [Sip] Last Call: The Session Initiation Protocol UPDATE Method to
 Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol
Working Group to consider publication of the following two I-Ds as
Proposed Standards:

 o The Session Initiation Protocol UPDATE Method
	<draft-ietf-sip-update-02.txt>

 o Integration of Resource Management and SIP 
	<draft-ietf-sip-manyfolks-resource-07.txt> 

The WG also asked the IESG to consider publication of the following two
I-Ds as Informational RFCs:

 o HTTP Digest Authentication Using AKA
	<draft-ietf-sip-digest-aka-01.txt>

 o SIP Extensions for Media Authorization
	<draft-ietf-sip-call-auth-04.txt>




The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by May 15, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-update-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-07.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-digest-aka-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-call-auth-04.txt





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



From daemon@optimus.ietf.org  Wed May  1 12:08:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05672
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 12:08:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA23719
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 12:08:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20823;
	Wed, 1 May 2002 11:30:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20775
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 11:30:26 -0400 (EDT)
Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03250
	for <sip@ietf.org>; Wed, 1 May 2002 11:30:23 -0400 (EDT)
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by ithilien.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g41FUH6v022801;
	Wed, 1 May 2002 08:30:18 -0700 (PDT)
Received: from MAHENDRA.qualcomm.com (mahendra.qualcomm.com [129.46.75.104])
	by magus.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g41FUGVl017349;
	Wed, 1 May 2002 08:30:16 -0700 (PDT)
Message-Id: <5.1.0.14.2.20020501082045.02932360@clea.qualcomm.com>
X-Sender: mahendra@clea.qualcomm.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 May 2002 08:30:15 -0700
To: sip@ietf.org
From: AC Mahendran <mahendra@qualcomm.com>
Subject: Re: [Sip] I-D
  ACTION:draft-henrikson-sip-original-dialog-id-00.txt
Cc: ehenrikson@lucent.com
In-Reply-To: <200205011125.HAA20103@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


Eric:

Comments...

1) In Section 5.4, Order of "Via" header is incorrect in transactions F2, 
F3, F5. Also, the branch values in these headers are not following the 
convention of 2543-bis.

2) In section 5.4 (in F2 & F3 transactions), the tag values in 
"P-Original-Dialog-ID" header don't match the definition of the header i.e 
the tags should be "od-from-tag",  "od-to-tag", "od-call-id" instead of "tag".

3) In section 5.4, the text says the following:
"This example shows the message sequence for an INVITE transaction 
originating from UA1 eventually arriving at UA2. P2 is an outbound proxy 
for UA1 which routes the request to an Application Server P2. "

In the second line, the first occurrence of P2 should be replaced with P1.


thanks,
AC

At 07:25 AM 5/1/2002 -0400, you wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Private SIP Extension for Original Dialog 
> Identifier
>         Author(s)       : E. Henrikson
>         Filename        : draft-henrikson-sip-original-dialog-id-00.txt
>         Pages           : 7
>         Date            : 30-Apr-02
>
>This document proposes a private SIP extension header used in
>conjunction with INVITE requests to provide a mechanism by which a
>stateful proxy may associate an INVITE request processed earlier
>with the INVITE request that is being currently processed. The
>association is needed by the Serving Call Session Control Function
>(S-CSCF) from the Third Generation Partnership Project (3GPP)
>architecture to ensure proper routing of an INVITE request with
>3GPP Application Servers (AS). A S-CSCF may route an INVITE request
>to multiple AS, as indicated by a subscriber profile, and each AS
>may be a B2BUA. The S-CSCF needs to keep track of each AS contacted
>and know that an incoming INVITE request is related to a previous
>outgoing INVITE request such that each AS may receive the INVITE
>request before it is sent on towards the intended destination. When
>a B2BUA AS is  involved, there is currently not a way to associate
>the incoming INVITE request with the previously sent INVITE request
>at the S-CSCF. The P-Original-Dialog-ID header provides a way to
>accomplish this association. The same mechanism may be applied to
>any SIP method that is used to initiate a dialog.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-henrikson-sip-original-dialog-id-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         mailserv@ietf.org.
>In the body type:
>         "FILE 
> /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <20020430135712.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt>



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



From daemon@optimus.ietf.org  Wed May  1 12:53:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08189
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 12:52:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA26652
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 12:53:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24422;
	Wed, 1 May 2002 12:22:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24381
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 12:21:57 -0400 (EDT)
Received: from odin.isw.intel.com (swfdns01.isw.intel.com [192.55.37.143])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06569
	for <sip@ietf.org>; Wed, 1 May 2002 12:21:54 -0400 (EDT)
Received: from swsmsxvs01.isw.intel.com (swsmsxvs01.isw.intel.com [172.28.130.22])
	by odin.isw.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.35 2002/04/27 00:24:14 root Exp $) with SMTP id g41GLPK08615
	for <sip@ietf.org>; Wed, 1 May 2002 16:21:25 GMT
Received: from swsmsx17.isw.intel.com ([172.28.130.21])
 by swsmsxvs01.isw.intel.com (NAVGW 2.5.1.16) with SMTP id M2002050117183227791
 ; Wed, 01 May 2002 17:18:32 +0100
Received: by swsmsx17.isw.intel.com with Internet Mail Service (5.5.2653.19)
	id <2645Q6CG>; Wed, 1 May 2002 17:24:33 +0100
Message-ID: <9985493A802AD5118C4E009027462753015CF89B@swsmsx34.isw.intel.com>
From: "Finnie, Donald" <donald.finnie@intel.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Cc: "'dwillis@dynamicsoft.com'" <dwillis@dynamicsoft.com>,
        "'bernhard.honeisen@nokia.com'" <bernhard.honeisen@nokia.com>
Date: Wed, 1 May 2002 17:25:56 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Comments on draft-willis-sip-path-04
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Section 2. "Applicability Statement" seems to have some ambiguous wording in
my opinion.  

2.2 says "One or more of the intermediate proxies MUST be visited by
messages between REGISTRAR and UA."

The use of the words "between" and "messages" seem ambiguous.  I assume this
refers only to dialog-initiating messages sent *from* REGISTRAR *to* UA?  If
my understanding of the Path mechanism is correct, it does not effect INVITE
messages, for example, sent from UA to some target via REGISTRAR/home
service proxy.  Nor does it imply Record-Routing at intermediate proxies so
they will only remain in the signalling path if they choose to Record-Route.


2.2 says "The same set of proxies must be visited by messages between a home
service proxy and UA.  That is,  the proxy route between  the UA and its
home service proxy is identical to the proxy route between the UA and its
registrar."

The Path mechanism only forces this situation for incoming messages arriving
at the registrar/home service proxy destined to the UA. Correct?

Regards

Donald Finnie

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



From daemon@optimus.ietf.org  Wed May  1 13:24:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09700
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 13:24:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA28683
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 13:24:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26944;
	Wed, 1 May 2002 12:56:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25986
	for <sip@optimus.ietf.org>; Wed, 1 May 2002 12:35:30 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07481
	for <sip@ietf.org>; Wed, 1 May 2002 12:35:28 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by hoemail1.firewall.lucent.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g41GYxG01374
	for <sip@ietf.org>; Wed, 1 May 2002 12:34:59 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21)
	id <J23Q3CAJ>; Wed, 1 May 2002 11:34:59 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C023E9F38@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: "'AC Mahendran'" <mahendra@qualcomm.com>, sip@ietf.org
Subject: RE: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-00.tx
	t
Date: Wed, 1 May 2002 11:34:55 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Thank you for your comments AC.  I will make the changes as you suggested.

Eric

-----Original Message-----
From: AC Mahendran [mailto:mahendra@qualcomm.com]
Sent: Wednesday, May 01, 2002 8:30 AM
To: sip@ietf.org
Cc: Henrikson, Eric H (Eric)
Subject: Re: [Sip] I-D
ACTION:draft-henrikson-sip-original-dialog-id-00.txt



Eric:

Comments...

1) In Section 5.4, Order of "Via" header is incorrect in transactions F2, 
F3, F5. Also, the branch values in these headers are not following the 
convention of 2543-bis.

2) In section 5.4 (in F2 & F3 transactions), the tag values in 
"P-Original-Dialog-ID" header don't match the definition of the header i.e 
the tags should be "od-from-tag",  "od-to-tag", "od-call-id" instead of
"tag".

3) In section 5.4, the text says the following:
"This example shows the message sequence for an INVITE transaction 
originating from UA1 eventually arriving at UA2. P2 is an outbound proxy 
for UA1 which routes the request to an Application Server P2. "

In the second line, the first occurrence of P2 should be replaced with P1.


thanks,
AC

At 07:25 AM 5/1/2002 -0400, you wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>         Title           : Private SIP Extension for Original Dialog 
> Identifier
>         Author(s)       : E. Henrikson
>         Filename        : draft-henrikson-sip-original-dialog-id-00.txt
>         Pages           : 7
>         Date            : 30-Apr-02
>
>This document proposes a private SIP extension header used in
>conjunction with INVITE requests to provide a mechanism by which a
>stateful proxy may associate an INVITE request processed earlier
>with the INVITE request that is being currently processed. The
>association is needed by the Serving Call Session Control Function
>(S-CSCF) from the Third Generation Partnership Project (3GPP)
>architecture to ensure proper routing of an INVITE request with
>3GPP Application Servers (AS). A S-CSCF may route an INVITE request
>to multiple AS, as indicated by a subscriber profile, and each AS
>may be a B2BUA. The S-CSCF needs to keep track of each AS contacted
>and know that an incoming INVITE request is related to a previous
>outgoing INVITE request such that each AS may receive the INVITE
>request before it is sent on towards the intended destination. When
>a B2BUA AS is  involved, there is currently not a way to associate
>the incoming INVITE request with the previously sent INVITE request
>at the S-CSCF. The P-Original-Dialog-ID header provides a way to
>accomplish this association. The same mechanism may be applied to
>any SIP method that is used to initiate a dialog.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-
00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-henrikson-sip-original-dialog-id-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         mailserv@ietf.org.
>In the body type:
>         "FILE 
> /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <20020430135712.I-D@ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-
00.txt>



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



From daemon@ns.ietf.org  Wed May  1 17:47:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07653
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 17:47:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA11611
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 17:47:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10052;
	Wed, 1 May 2002 17:13:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10024
	for <sip@ns.ietf.org>; Wed, 1 May 2002 17:13:04 -0400 (EDT)
Received: from broadsoft.com (broadsoft.com [198.104.184.110])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02584
	for <sip@ietf.org>; Wed, 1 May 2002 17:13:01 -0400 (EDT)
Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.11.6) id g41LD3L08110; Wed, 1 May 2002 17:13:03 -0400 (EDT)
Reply-To: <brett@broadsoft.com>
From: "Brett Tate" <brett@broadsoft.com>
To: <sip@ietf.org>
Date: Wed, 1 May 2002 17:13:31 -0400
Message-ID: <000901c1f155$0c972230$2b01a8c0@broadsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] refusing early media
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

What draft reflects the "accepted" working 
group solution for early media?

There were various discussions and drafts 
attempting to resolve the forking issues 
related to two devices attempting to provide 
early media.  I cannot recall or find which 
solution/message-flow was finally chosen.

Thanks in advance.


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



From daemon@ns.ietf.org  Wed May  1 18:33:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12720
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 18:33:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA13829
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 18:33:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12345;
	Wed, 1 May 2002 18:01:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12303
	for <sip@ns.ietf.org>; Wed, 1 May 2002 18:00:55 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09454
	for <sip@ietf.org>; Wed, 1 May 2002 18:00:51 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g41M0Rx00401;
	Wed, 1 May 2002 17:00:27 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <J4QHTM2P>; Wed, 1 May 2002 17:00:23 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B04E@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: sip@ietf.org, "'rohan@cisco.com'" <rohan@cisco.com>
Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-replaces-01.txt
Date: Wed, 1 May 2002 17:00:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F15B.966BCE10"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1F15B.966BCE10
Content-Type: text/plain;
	charset="iso-8859-1"

Rohan,

Some comments:

(1)Section 4.1 says "In other words the to-tag is compared to the local tag,
and the from-tag is compared to the remote tag." However in section 5.2
INV/200 estalish from-tag (operator) = 7743 and to-tag (Call Center) = 6472.
However the call from the customer to Call Center has
Replaces:425928@dhcp23311.acme.com;to-tag=7743;from-tag=6472, thus the Call
Center will _not_ be able to match correctly based on sections 4.1 rule.

(2) Section 5.2 the NOTIFY sent to from Customer to Operator when the
Customer receives 182 (Queued). Then this transaction is BYE'd. Now we
_cannot_ send another NOTIFY/200 from Customer to Operator as shown - it
will result in a 481.

(3) Same for section 5.7 (and section 5.8) - once Bob gets a 687, he BYE's
the call with Alice. Then at the bottom of call Flow, Alice tries to send a
NOTIFY for the REFER, this will result in a 481.

(3) Section 5.8 Invite from Proxy (forking Alice) INVITE (2a) and (2b) goes
to C1. I think INVITE (2b) should go to C2.

(4) Section 5.6, just for grins, how does Alice get the Replaces information
to replace the dialog between Bob and Old Timer :).

Thats what I have from my initial reading.

Sriram 

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Sip] I-D ACTION:draft-ietf-sip-replaces-01.txt</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>Some comments:</FONT>
</P>

<P><FONT SIZE=3D2>(1)Section 4.1 says &quot;In other words the to-tag =
is compared to the local tag, and the from-tag is compared to the =
remote tag.&quot; However in section 5.2 INV/200 estalish from-tag =
(operator) =3D 7743 and to-tag (Call Center) =3D 6472. However the call =
from the customer to Call Center has =
Replaces:425928@dhcp23311.acme.com;to-tag=3D7743;from-tag=3D6472, thus =
the Call Center will _not_ be able to match correctly based on sections =
4.1 rule.</FONT></P>

<P><FONT SIZE=3D2>(2) Section 5.2 the NOTIFY sent to from Customer to =
Operator when the Customer receives 182 (Queued). Then this transaction =
is BYE'd. Now we _cannot_ send another NOTIFY/200 from Customer to =
Operator as shown - it will result in a 481.</FONT></P>

<P><FONT SIZE=3D2>(3) Same for section 5.7 (and section 5.8) - once Bob =
gets a 687, he BYE's the call with Alice. Then at the bottom of call =
Flow, Alice tries to send a NOTIFY for the REFER, this will result in a =
481.</FONT></P>

<P><FONT SIZE=3D2>(3) Section 5.8 Invite from Proxy (forking Alice) =
INVITE (2a) and (2b) goes to C1. I think INVITE (2b) should go to =
C2.</FONT>
</P>

<P><FONT SIZE=3D2>(4) Section 5.6, just for grins, how does Alice get =
the Replaces information to replace the dialog between Bob and Old =
Timer :).</FONT></P>

<P><FONT SIZE=3D2>Thats what I have from my initial reading.</FONT>
</P>

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

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

</BODY>
</HTML>
------_=_NextPart_001_01C1F15B.966BCE10--

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



From daemon@ns.ietf.org  Wed May  1 19:43:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21481
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 19:43:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA17075
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 19:43:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15600;
	Wed, 1 May 2002 19:14:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15557
	for <sip@ns.ietf.org>; Wed, 1 May 2002 19:14:24 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18241
	for <sip@ietf.org>; Wed, 1 May 2002 19:14:20 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g41NDrp6029831;
	Wed, 1 May 2002 16:13:53 -0700 (PDT)
Received: from dhcp-128-107-142-136.cisco.com (dhcp-128-107-142-136.cisco.com [128.107.142.136])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AAC55618;
	Wed, 1 May 2002 16:13:52 -0700 (PDT)
Date: Wed, 1 May 2002 16:10:41 -0700 (Pacific Daylight Time)
From: Rohan Mahy <rohan@cisco.com>
To: sip@ietf.org, <sipping@ietg.org>
Message-ID: <Pine.WNT.4.44.0205011607160.-701063@chorizo.rapidconvergence.com>
X-X-Sender: rmahy@imop.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Sip] interim agenda (redux)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

OK, Hopefully the last interim agenda I will send out, also available at:

http://www.softarmor.com/sipwg/meets/interim-may-02/agenda2.html

thanks,
-rohan

Rohan Mahy
SIPPING co-chair

--------------

SIP/SIPPING WG Agenda, Interim Meeting, May 6 and 7, 2002
Room S225 (2nd Floor of South Hall)
Las Vegas Convention Center
3150 Paradise Road at Convention Center Drive
Las Vegas, Nevada, USA
--------------------------------------------------------------------------------

Monday, May 6
08:30 Welcome, Logistics, Agenda Bashing -- Rohan Mahy

09:00 Multiparty Apps Framework and Conferencing Requirements -- Dan
Petrie or Orit Levin
draft-ietf-sipping-cc-framework-00.txt
draft-levin-sipping-conferencing-requirements-00.txt

10:30 REFER / Replaces / cc-transfer / service examples -- Robert Sparks,
Rohan Mahy, Alan Johnston
draft-ietf-sip-refer-02.txt
draft-sparks-sip-refer-split-00.txt
draft-sparks-sip-referredby-split-00.txt
draft-sparks-sip-sec-options-00.txt
draft-sparks-sip-mimetypes-03.txt
draft-ietf-sip-replaces-01.txt
draft-ietf-sip-cc-transfer-05.txt
draft-ietf-sipping-service-examples-01.txt

13:00 Lunch

14:00 The call-info and conference-info packages -- Jonathan Rosenberg
draft-rosenberg-sip-call-package-01.txt

15:30 Request History (Requirements) -- Mary Barnes and Mark Watson
draft-watson-sipping-req-history-01.txt

16:15 URI as service indicator -- Eric Burger
RFC 3087 - Service Context using SIP URIs

17:00 Binding Published data to SIP -- Ben Campbell
very long mailing list thread

18:00 Wrap

Tuesday, May 7
08:30 AAA requirements (Requirements) -- John Loughney and Gonzalo
Camarillo
draft-calhoun-sip-aaa-reqs-04.txt
draft-loughney-sip-aaa-req-00.txt

10:30 Content Indirection
draft-olson-sipping-content-indirect-00.txt

11:15 Key Events/ Stimulus Markup -- Jonathan Rosenberg
draft-culpepper-sipping-app-interact-reqs-01.txt
draft-rosenberg-sipping-markup-00.txt

12:00 Lunch

13:00 Privacy and Network Asserted Identity (Direction Forward) -- Cullen
Jennings
draft-watson-sipping-nai-reqs-00.txt
draft-ietf-sip-privacy-04.txt
draft-peterson-sip-privacy-longterm-00.txt
draft-peterson-sip-identity-00.txt

16:30 Future Security Needs (Discussion)
draft-ietf-sip-sec-agree-00.txt
draft-undery-sip-auth-00.txt
draft-thomas-sip-sec-req-00.txt

18:00 Wrap


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



From daemon@ns.ietf.org  Wed May  1 20:16:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27059
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 20:16:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA18687
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 20:16:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17397;
	Wed, 1 May 2002 19:51:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17367
	for <sip@ns.ietf.org>; Wed, 1 May 2002 19:51:00 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22456
	for <sip@ietf.org>; Wed, 1 May 2002 19:50:56 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.194])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g41NpmLC011406;
	Wed, 1 May 2002 19:51:49 -0400 (EDT)
Message-ID: <3CD07F3D.614E2687@dynamicsoft.com>
Date: Wed, 01 May 2002 19:50:21 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: vishal <vishal@knowsys.net>
CC: Bobby Sardana <sardana@obsoft.com>, sip@ietf.org
Subject: Re: [Sip] request/response over different transport
References: <009c01c1f0e2$9c0912c0$5601a8c0@knowsys.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

We thought about this problem a great deal for bis. The conclusion was
that sending the response over a different transport was too complex and
broke too many sip assumptions that exist throughout the spec.

Instead, the spec mandates the use of TCP when you are within a few
hundred bytes of the MTU. The few hundred byte headroom exists to handle
the majority of the cases Record-Route will cause an increase in the
response size. This doesn't guarantee that you won't get a response that
exceeds the MTU, but it reduces its probability.

more below.

vishal wrote:
> 
> Hi Bobby,
>       you are correct if message size is less than MTU size then
> response must be over UDP .....
> 
> some other problems are :
> 
>  when proxy forwards INVITE requests .It adds "Via:" field into it along
> with appropriate parametres ....if message is forwarded by many proxies
> then this message may become greater than MTU size in particular network
> ....how this  case should be handled ?
>     should next proxy establish TCP connection and then forward it OR
> reject this message?

Establish a TCP connection. This is discussed in Section 18 of bis.

> 
> If proxy forwards this message using TCP and UAS receives INVITE over
> TCP then UAS response will be sent over TCP  and UAC should be prepared
> to receive response over TCP or UDP  for its previous INVITE over UDP
> request.

UDP. There is a proxy that straddles UDP/TCP. It will receive the
resposne over TCP, and forward it towards the UAC over UDP.

-Jonathan R.

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

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



From daemon@ns.ietf.org  Wed May  1 20:30:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29490
	for <sip-archive@odin.ietf.org>; Wed, 1 May 2002 20:30:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA18672
	for sip-archive@odin.ietf.org; Wed, 1 May 2002 20:15:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17145;
	Wed, 1 May 2002 19:45:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA17116
	for <sip@ns.ietf.org>; Wed, 1 May 2002 19:45:21 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21738
	for <sip@ietf.org>; Wed, 1 May 2002 19:45:17 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.194])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g41NkBLC011402;
	Wed, 1 May 2002 19:46:12 -0400 (EDT)
Message-ID: <3CD07DEC.59408507@dynamicsoft.com>
Date: Wed, 01 May 2002 19:44:44 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: brett@broadsoft.com
CC: sip@ietf.org
Subject: Re: [Sip] refusing early media
References: <000901c1f155$0c972230$2b01a8c0@broadsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Brett Tate wrote:
> 
> What draft reflects the "accepted" working
> group solution for early media?

There is no current document that explicitly addresses early media (and
is current). The consensus was that the UNIFY proposal
(draft-rosenberg-sip-unify) provided the framework we would move forward
with. In that framework, the session state is totally decoupled from the
dialog state. The offer/answer exchange affects session state, and those
exchanges could be mapped into several sip message sequences. By mapping
them into messages exchanged before the sip invite completes (inv/183)
you get early media. Aspects of this were incorporated into bis,
therefore allowing early media to be provided with bis + 100rel.
However, bis+100rel alone is not sufficient, since you will need to
modify aspects of the session before the call is answered (to handle
forking, for example). That is the reason for the UPDATE draft
(draft-ietf-sip-update) now in IETF last call. The UPDATE draft actually
has a flow that shows early media.

I do think it would be valuable to have some more early media specific
call flows, as supported by bis and update. I am not sure we need a
separate document on early media per se. Perhaps just some example call
flows in the call flows or service examples doc would be sufficient.


-Jonathan R.

> 
> There were various discussions and drafts
> attempting to resolve the forking issues
> related to two devices attempting to provide
> early media.  I cannot recall or find which
> solution/message-flow was finally chosen.
> 
> Thanks in advance.
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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



From daemon@ns.ietf.org  Thu May  2 00:59:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05357
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 00:59:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA01048
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 00:59:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28912;
	Thu, 2 May 2002 00:15:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28846
	for <sip@ns.ietf.org>; Thu, 2 May 2002 00:15:28 -0400 (EDT)
Received: from relay.pair.com (relay1.pair.com [209.68.1.20])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00707
	for <sip@ietf.org>; Thu, 2 May 2002 00:15:25 -0400 (EDT)
Received: (qmail 25020 invoked from network); 2 May 2002 04:15:25 -0000
Received: from unknown (HELO dexceldesigns.com) (202.131.154.196)
  by relay1.pair.com with SMTP; 2 May 2002 04:15:25 -0000
X-pair-Authenticated: 202.131.154.196
Message-ID: <001401c1f0da$49ed26a0$0c010a64@DOMAIN>
From: Muruganantham D <murugananth@dexceldesigns.com>
To: <sip@ietf.org>, <sipping@ietf.org>
Date: Wed, 1 May 2002 12:04:46 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0011_01C1F108.63284360"
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-Mailserver: Sent using PostMaster (v4.1.11)
Subject: [Sip] Sip with Qsig
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C1F108.63284360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi!
 We are developing SIP application with QSIG Protocol, we are following =
those thing s specified in RFC 3204.Plz go through the=20
below things and guide us in the right direction.
=20
INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0

Via: SIP/2.0/UDP sc10.nortelnetworks.com

From: sip:14085655675@sc10.nortelnetworks.com

To: sip:14084955072@sc1.nortelnetworks.com

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com

CSeq: 1234 INVITE

Contact: <sip:14085655675@sc10.nortelnetworks.com>

Content-Length: 358

Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=3DISO-10646

v=3D0

o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4

s=3DSDP seminar

c=3DIN IP4 MG141.nortelnetworks.com

t=3D 2873397496 2873404696

m=3Daudio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-type:application/QSIG; version=3Diso

08 02 55 55 05 04 02 90 90 18 03 a1 83 01

70 0a 89 31 34 30 38 34 39 35 35 30 37 32

--unique-boundary-1--

How to proceed with these kind of messages?
For 1xx no content just with sip messages, For 200 OKwith SDP part like =
the above things, Is it correct or not?

Thanks in advance,
Regards,
D.Murugananth


*************************************************************************=
*************************
Muruganantham.D., Dexcel Electronics Designs pvt Ltd., Airport road, =
Bangalore-8

------=_NextPart_000_0011_01C1F108.63284360
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.2462.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;We are developing SIP application =
with QSIG=20
Protocol,&nbsp;we are following those thing s specified in RFC 3204.Plz =
go=20
through the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>below things and guide us in the right=20
direction.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT><FONT face=3DArial =
size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>
<P>INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0</P>
<P>Via: SIP/2.0/UDP sc10.nortelnetworks.com</P>
<P>From: sip:14085655675@sc10.nortelnetworks.com</P>
<P>To: sip:14084955072@sc1.nortelnetworks.com</P>
<P>Call-ID: 1231999021712095500999@sc12.nortelnetworks.com</P>
<P>CSeq: 1234 INVITE</P>
<P>Contact: &lt;sip:14085655675@sc10.nortelnetworks.com&gt;</P>
<P>Content-Length: 358</P>
<P>Content-Type: multipart/mixed; boundary=3Dunique-boundary-1</P>
<P>MIME-Version: 1.0</P>
<P>--unique-boundary-1</P>
<P>Content-Type: application/SDP; charset=3DISO-10646</P>
<P>v=3D0</P>
<P>o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4</P>
<P>s=3DSDP seminar</P>
<P>c=3DIN IP4 MG141.nortelnetworks.com</P>
<P>t=3D 2873397496 2873404696</P>
<P>m=3Daudio 9092 RTP/AVP 0 3 4</P>
<P>--unique-boundary-1</P>
<P>Content-type:application/QSIG; version=3Diso</P>
<P>08 02 55 55 05 04 02 90 90 18 03 a1 83 01</P>
<P>70 0a 89 31 34 30 38 34 39 35 35 30 37 32</P>
<P>--unique-boundary-1--</P></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How to proceed with these kind of=20
messages?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>For 1xx no content just with sip =
messages, For 200=20
OKwith SDP part like the above things, Is it correct or =
not?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>D.Murugananth</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>****************************************************************=
**********************************<BR>Muruganantham.D.,=20
Dexcel Electronics Designs pvt Ltd., Airport road,=20
Bangalore-8</FONT></DIV></BODY></HTML>

<br>--------------------------------------------------------------<br>Dexcel Electronics Designs (P) Ltd., Bangalore, India<br>
------=_NextPart_000_0011_01C1F108.63284360--


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



From daemon@ns.ietf.org  Thu May  2 00:59:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05429
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 00:59:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA01062
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 00:59:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29064;
	Thu, 2 May 2002 00:15:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28869
	for <sip@ns.ietf.org>; Thu, 2 May 2002 00:15:30 -0400 (EDT)
Received: from relay.pair.com (relay1.pair.com [209.68.1.20])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00724
	for <sip@ietf.org>; Thu, 2 May 2002 00:15:27 -0400 (EDT)
Received: (qmail 25030 invoked from network); 2 May 2002 04:15:27 -0000
Received: from unknown (HELO dexceldesigns.com) (202.131.154.196)
  by relay1.pair.com with SMTP; 2 May 2002 04:15:27 -0000
X-pair-Authenticated: 202.131.154.196
Message-ID: <001401c1f0da$49ed26a0$0c010a64@DOMAIN>
From: Muruganantham D <murugananth@dexceldesigns.com>
To: <sip@ietf.org>, <sipping@ietf.org>
Date: Wed, 1 May 2002 12:04:46 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0011_01C1F108.63284360"
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-Mailserver: Sent using PostMaster (v4.1.11)
Subject: [Sip] Sip with Qsig
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C1F108.63284360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi!
 We are developing SIP application with QSIG Protocol, we are following =
those thing s specified in RFC 3204.Plz go through the=20
below things and guide us in the right direction.
=20
INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0

Via: SIP/2.0/UDP sc10.nortelnetworks.com

From: sip:14085655675@sc10.nortelnetworks.com

To: sip:14084955072@sc1.nortelnetworks.com

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com

CSeq: 1234 INVITE

Contact: <sip:14085655675@sc10.nortelnetworks.com>

Content-Length: 358

Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=3DISO-10646

v=3D0

o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4

s=3DSDP seminar

c=3DIN IP4 MG141.nortelnetworks.com

t=3D 2873397496 2873404696

m=3Daudio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-type:application/QSIG; version=3Diso

08 02 55 55 05 04 02 90 90 18 03 a1 83 01

70 0a 89 31 34 30 38 34 39 35 35 30 37 32

--unique-boundary-1--

How to proceed with these kind of messages?
For 1xx no content just with sip messages, For 200 OKwith SDP part like =
the above things, Is it correct or not?

Thanks in advance,
Regards,
D.Murugananth


*************************************************************************=
*************************
Muruganantham.D., Dexcel Electronics Designs pvt Ltd., Airport road, =
Bangalore-8

------=_NextPart_000_0011_01C1F108.63284360
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.2462.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;We are developing SIP application =
with QSIG=20
Protocol,&nbsp;we are following those thing s specified in RFC 3204.Plz =
go=20
through the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>below things and guide us in the right=20
direction.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT><FONT face=3DArial =
size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>
<P>INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0</P>
<P>Via: SIP/2.0/UDP sc10.nortelnetworks.com</P>
<P>From: sip:14085655675@sc10.nortelnetworks.com</P>
<P>To: sip:14084955072@sc1.nortelnetworks.com</P>
<P>Call-ID: 1231999021712095500999@sc12.nortelnetworks.com</P>
<P>CSeq: 1234 INVITE</P>
<P>Contact: &lt;sip:14085655675@sc10.nortelnetworks.com&gt;</P>
<P>Content-Length: 358</P>
<P>Content-Type: multipart/mixed; boundary=3Dunique-boundary-1</P>
<P>MIME-Version: 1.0</P>
<P>--unique-boundary-1</P>
<P>Content-Type: application/SDP; charset=3DISO-10646</P>
<P>v=3D0</P>
<P>o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4</P>
<P>s=3DSDP seminar</P>
<P>c=3DIN IP4 MG141.nortelnetworks.com</P>
<P>t=3D 2873397496 2873404696</P>
<P>m=3Daudio 9092 RTP/AVP 0 3 4</P>
<P>--unique-boundary-1</P>
<P>Content-type:application/QSIG; version=3Diso</P>
<P>08 02 55 55 05 04 02 90 90 18 03 a1 83 01</P>
<P>70 0a 89 31 34 30 38 34 39 35 35 30 37 32</P>
<P>--unique-boundary-1--</P></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How to proceed with these kind of=20
messages?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>For 1xx no content just with sip =
messages, For 200=20
OKwith SDP part like the above things, Is it correct or =
not?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>D.Murugananth</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>****************************************************************=
**********************************<BR>Muruganantham.D.,=20
Dexcel Electronics Designs pvt Ltd., Airport road,=20
Bangalore-8</FONT></DIV></BODY></HTML>

<br>--------------------------------------------------------------<br>Dexcel Electronics Designs (P) Ltd., Bangalore, India<br>
------=_NextPart_000_0011_01C1F108.63284360--


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



From daemon@ns.ietf.org  Thu May  2 01:04:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05883
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 01:04:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA01632
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 01:04:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA29015;
	Thu, 2 May 2002 00:15:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28851
	for <sip@ns.ietf.org>; Thu, 2 May 2002 00:15:29 -0400 (EDT)
Received: from relay.pair.com (relay1.pair.com [209.68.1.20])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00717
	for <sip@ietf.org>; Thu, 2 May 2002 00:15:26 -0400 (EDT)
Received: (qmail 25027 invoked from network); 2 May 2002 04:15:26 -0000
Received: from unknown (HELO dexceldesigns.com) (202.131.154.196)
  by relay1.pair.com with SMTP; 2 May 2002 04:15:26 -0000
X-pair-Authenticated: 202.131.154.196
Message-ID: <001401c1f0da$49ed26a0$0c010a64@DOMAIN>
From: Muruganantham D <murugananth@dexceldesigns.com>
To: <sip@ietf.org>, <sipping@ietf.org>
Date: Wed, 1 May 2002 12:04:46 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;	boundary="----=_NextPart_000_0011_01C1F108.63284360"
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-Mailserver: Sent using PostMaster (v4.1.11)
Subject: [Sip] Sip with Qsig
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01C1F108.63284360
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi!
 We are developing SIP application with QSIG Protocol, we are following =
those thing s specified in RFC 3204.Plz go through the=20
below things and guide us in the right direction.
=20
INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0

Via: SIP/2.0/UDP sc10.nortelnetworks.com

From: sip:14085655675@sc10.nortelnetworks.com

To: sip:14084955072@sc1.nortelnetworks.com

Call-ID: 1231999021712095500999@sc12.nortelnetworks.com

CSeq: 1234 INVITE

Contact: <sip:14085655675@sc10.nortelnetworks.com>

Content-Length: 358

Content-Type: multipart/mixed; boundary=3Dunique-boundary-1

MIME-Version: 1.0

--unique-boundary-1

Content-Type: application/SDP; charset=3DISO-10646

v=3D0

o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4

s=3DSDP seminar

c=3DIN IP4 MG141.nortelnetworks.com

t=3D 2873397496 2873404696

m=3Daudio 9092 RTP/AVP 0 3 4

--unique-boundary-1

Content-type:application/QSIG; version=3Diso

08 02 55 55 05 04 02 90 90 18 03 a1 83 01

70 0a 89 31 34 30 38 34 39 35 35 30 37 32

--unique-boundary-1--

How to proceed with these kind of messages?
For 1xx no content just with sip messages, For 200 OKwith SDP part like =
the above things, Is it correct or not?

Thanks in advance,
Regards,
D.Murugananth


*************************************************************************=
*************************
Muruganantham.D., Dexcel Electronics Designs pvt Ltd., Airport road, =
Bangalore-8

------=_NextPart_000_0011_01C1F108.63284360
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.2462.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;We are developing SIP application =
with QSIG=20
Protocol,&nbsp;we are following those thing s specified in RFC 3204.Plz =
go=20
through the </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>below things and guide us in the right=20
direction.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;</FONT><FONT face=3DArial =
size=3D2></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>
<P>INVITE sip:14084955072@sc1.nortelnetworks.com SIP/2.0</P>
<P>Via: SIP/2.0/UDP sc10.nortelnetworks.com</P>
<P>From: sip:14085655675@sc10.nortelnetworks.com</P>
<P>To: sip:14084955072@sc1.nortelnetworks.com</P>
<P>Call-ID: 1231999021712095500999@sc12.nortelnetworks.com</P>
<P>CSeq: 1234 INVITE</P>
<P>Contact: &lt;sip:14085655675@sc10.nortelnetworks.com&gt;</P>
<P>Content-Length: 358</P>
<P>Content-Type: multipart/mixed; boundary=3Dunique-boundary-1</P>
<P>MIME-Version: 1.0</P>
<P>--unique-boundary-1</P>
<P>Content-Type: application/SDP; charset=3DISO-10646</P>
<P>v=3D0</P>
<P>o=3Daudet 2890844526 2890842807 5 IN IP4 134.177.64.4</P>
<P>s=3DSDP seminar</P>
<P>c=3DIN IP4 MG141.nortelnetworks.com</P>
<P>t=3D 2873397496 2873404696</P>
<P>m=3Daudio 9092 RTP/AVP 0 3 4</P>
<P>--unique-boundary-1</P>
<P>Content-type:application/QSIG; version=3Diso</P>
<P>08 02 55 55 05 04 02 90 90 18 03 a1 83 01</P>
<P>70 0a 89 31 34 30 38 34 39 35 35 30 37 32</P>
<P>--unique-boundary-1--</P></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>How to proceed with these kind of=20
messages?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>For 1xx no content just with sip =
messages, For 200=20
OKwith SDP part like the above things, Is it correct or =
not?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in advance,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>D.Murugananth</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>****************************************************************=
**********************************<BR>Muruganantham.D.,=20
Dexcel Electronics Designs pvt Ltd., Airport road,=20
Bangalore-8</FONT></DIV></BODY></HTML>

<br>--------------------------------------------------------------<br>Dexcel Electronics Designs (P) Ltd., Bangalore, India<br>
------=_NextPart_000_0011_01C1F108.63284360--


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



From daemon@optimus.ietf.org  Thu May  2 05:09:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03039
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 05:09:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA21337
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 05:09:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18979;
	Thu, 2 May 2002 04:30:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA18867
	for <sip@optimus.ietf.org>; Thu, 2 May 2002 04:29:58 -0400 (EDT)
Received: from gw-nl3.philips.com (gw-nl3.philips.com [212.153.190.5])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01243;
	Thu, 2 May 2002 04:29:55 -0400 (EDT)
From: frank.derks@philips.com
Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23])
	by gw-nl3.philips.com (Postfix) with ESMTP
	id 9AFB43B255; Thu,  2 May 2002 10:29:26 +0200 (MET DST)
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA13093; Thu, 2 May 2002 10:29:26 +0200 (MET DST)
Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA04200; Thu, 2 May 2002 10:29:25 +0200 (MET DST)
To: Muruganantham D <murugananth@dexceldesigns.com>
Cc: sip@ietf.org, sipping@ietf.org, sipping-admin@ietf.org
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF042982EC.7B336748-ONC1256BAD.002E79E9@diamond.philips.com>
Date: Thu, 2 May 2002 10:27:56 +0200
X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at
 02/05/2002 10:30:24,
	Serialize complete at 02/05/2002 10:30:24
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 002EA137C1256BAD_="
Subject: [Sip] Re: [Sipping] Sip with Qsig
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

Check out the following:

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.


                 Title                           : Interworking between 
SIP and QSIG
                 Author(s)               : J. Elwell
                 Filename                : 
draft-elwell-sipping-qsig2sip-00.txt
                 Pages                           : 43
                 Date                            : 25-Apr-02
 
This document specifies interworking between the Session Initiation 
Protocol (SIP) and QSIG within corporate networks. SIP is an Internet 
application-layer control (signalling) protocol for creating, 
modifying, and terminating sessions with one or more participants. 
These sessions include, in particular, telephone calls. QSIG is a 
signalling protocol for creating, modifying and terminating circuit-
switched calls, in particular telephone calls, within Private 
Integrated Services Networks (PISNs). QSIG is specified in a number 
of ECMA Standards and published also as ISO/IEC standards. 
As the support of telephony within corporate networks evolves from 
circuit-switched technology to Internet technology, the two 
technologies will co-exist in many networks for a period, perhaps 
several years. Therefore there is a need to be able to establish, 
modify and terminate sessions involving a participant in the SIP 
network and a participant in the QSIG network. Such calls are 
supported by gateways that perform interworking between SIP and QSIG. 
This document is a product of the authors' activities in ECMA 
(www.ecma.ch) on interoperability of QSIG with IP networks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-00.txt

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

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

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


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

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


--=_alternative 002EA137C1256BAD_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="sans-serif">Check out the following:</font>
<br>
<br><font size=2 face="Courier New">A New Internet-Draft is available from the on-line Internet-Drafts directories.<br>
<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Title &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;: Interworking between SIP and QSIG<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Author(s) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : J. Elwell<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Filename &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : draft-elwell-sipping-qsig2sip-00.txt<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Pages &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;: 43<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Date &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;: 25-Apr-02<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
This document specifies interworking between the Session Initiation <br>
Protocol (SIP) and QSIG within corporate networks. SIP is an Internet <br>
application-layer control (signalling) protocol for creating, <br>
modifying, and terminating sessions with one or more participants. <br>
These sessions include, in particular, telephone calls. QSIG is a <br>
signalling protocol for creating, modifying and terminating circuit-<br>
switched calls, in particular telephone calls, within Private <br>
Integrated Services Networks (PISNs). QSIG is specified in a number <br>
of ECMA Standards and published also as ISO/IEC standards. <br>
As the support of telephony within corporate networks evolves from <br>
circuit-switched technology to Internet technology, the two <br>
technologies will co-exist in many networks for a period, perhaps <br>
several years. Therefore there is a need to be able to establish, <br>
modify and terminate sessions involving a participant in the SIP <br>
network and a participant in the QSIG network. Such calls are <br>
supported by gateways that perform interworking between SIP and QSIG. <br>
This document is a product of the authors' activities in ECMA <br>
(www.ecma.ch) on interoperability of QSIG with IP networks.<br>
<br>
A URL for this Internet-Draft is:<br>
http://www.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-00.txt<br>
<br>
To remove yourself from the IETF Announcement list, send a message to <br>
ietf-announce-request with the word unsubscribe in the body of the message.<br>
<br>
Internet-Drafts are also available by anonymous FTP. Login with the username<br>
&quot;anonymous&quot; and a password of your e-mail address. After logging in,<br>
type &quot;cd internet-drafts&quot; and then<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;get draft-elwell-sipping-qsig2sip-00.txt&quot;.<br>
<br>
A list of Internet-Drafts directories can be found in<br>
http://www.ietf.org/shadow.html <br>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<br>
<br>
<br>
Internet-Drafts can also be obtained by e-mail.<br>
<br>
Send a message to:<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; mailserv@ietf.org.<br>
In the body type:<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;FILE /internet-drafts/draft-elwell-sipping-qsig2sip-00.txt&quot;.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>
NOTE: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The mail server at ietf.org can return the document in<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; MIME-encoded form by using the &quot;mpack&quot; utility. &nbsp;To use this<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; feature, insert the command &quot;ENCODING mime&quot; before the &quot;FILE&quot;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; command. &nbsp;To decode the response(s), you will need &quot;munpack&quot; or<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; a MIME-compliant mail reader. &nbsp;Different MIME-compliant mail readers<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; exhibit different behavior, especially when dealing with<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &quot;multipart&quot; MIME messages (i.e. documents which have been split<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; up into multiple messages), so check your local documentation on<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; how to manipulate these messages.<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>
Below is the data which will enable a MIME compliant mail reader<br>
implementation to automatically retrieve the ASCII version of the<br>
Internet-Draft.<br>
</font><font size=2 face="sans-serif">ftp://anonymous@ftp.ietf.org/internet-drafts/draft-elwell-sipping-qsig2sip-00.txt<br>
<br>
</font>
--=_alternative 002EA137C1256BAD_=--

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



From daemon@optimus.ietf.org  Thu May  2 06:36:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09442
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 06:36:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA26225
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 06:36:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24439;
	Thu, 2 May 2002 06:05:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24382
	for <sip@optimus.ietf.org>; Thu, 2 May 2002 06:05:35 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06441;
	Thu, 2 May 2002 06:05:31 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g42A5V0E006430;
	Thu, 2 May 2002 12:05:31 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g42A5Ukw028902;
	Thu, 2 May 2002 13:05:30 +0300 (EET DST)
Message-ID: <3CD10F64.D62B1E78@lmf.ericsson.se>
Date: Thu, 02 May 2002 13:05:24 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip <sip@ietf.org>, rohc <rohc@ietf.org>
References: <3CC7D4B6.4480B8AA@lmf.ericsson.se> <3CC80CEA.7341993D@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: [rohc] SigComp and SIP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan,

thanks for the comments. Answers inline:

Jonathan Rosenberg wrote:

> * Section 3 leaves out an important means for obtaining the URI -
> configuration.

I actually listed confirguation in the second set of bullets. The ones
that deal with URIs without comp=sigcomp. However, in another of your
comments you propose to get rid of that list.

I will remove the second list and add "configuration" as a bullet here.

> * I think a client MUST NOT send a sigcomp request to a server if it
> doesn't know whether it supports compression. Section 3 provides cases
> in which you can sort of guess whether it does. I don't like that. The
> guesses are just that - guesses, and may be wrong. 

Yes, I agree. I will turn the SHOULD NOT into a MUST NOT and remove
these bullets.


> * I think its worth noting a few things about this approach. First, a
> proxy that gets a request uncompressed, and wants to get it compressed
> in subsequent requests, can return a 301 with a contact header that has
> the comp parameter. This will result in a caching of the binding in the
> client that sent the request.

Yes. I believe this is already covered with the bullet below:

\item The URI was obtained from a \header{Contact} header field in a 3xx
or 485 response to the request.

> Secondly, a SIP element that implements
> this will need to be prepared to receive compressed or uncompressed
> messages on the same port, and thus will need to look at the cookie in
> the topmost bits to demux.

Yes, this is the basic idea behind this approach. I have added the
following text:

"A SIP element that supports compression will need to be prepared to
receive compressed and uncompressed messages on the same port. It will
perform demultiplexing based on the cookie in the topmost bits of every
compressed message."


> 
> > A response is sent to the host in the sent-by parameter of the Via
> >    header field. If the topmost Via header field contains the parameter
> >    comp=sigcomp, the response SHOULD be compressed. Otherwise, the
> >    response SHOULD NOT be compressed.
> 
> I would say MUST NOT be compressed. The criteria is - will things work
> if you violate this? If I send a compressed response to something which
> doesn't support it, the response is discarded. The result is total
> failure of the transaction. There is no recovrey. So, it should be MUST
> NOT.

OK, it will be a MUST NOT.
 
> >  A proxy performing Record-Route inspects the Record-Route and the
> >    Contact header fields in the response. It looks for the URI of the
> >    next upstream (closer to the user agent client) hop in the route set.
> >    If this URI contains the parameter comp=sigcomp, the proxy SHOULD add
> >    comp=sigcomp to its entry in the Record-Route header field.
> 
> Why? If the upstream element doesn't support this extension, the sigcomp
> parameter is ignored, and the message is sent uncompressed. Thats what
> you want. The decision about whether to insert a URI with the comp
> parameter should be entirely a local one.

This covers the following scenario:

UAC----P1-----P2-----UAS

The UAC sends an INITE to UAS. P2 records route, but P1 does not.
When the 200 OK for the INVITE reaches P2, the contact and RR header
fields will look like this:

Contact: UAS@domain.com;comp=sigcomp
RR: P2

If P2 does not add comp=sigcomp to his entry in the RR, UAC will be able
to receive compressed traffic (the contact has comp=sigcomp), but will
be unable to send compress traffic (the RR entry for P2 does not have
it).

Making P2 add comp=sigcomp resolves this asymmetry

Thanks for the comments,

Gonzalo

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



From daemon@optimus.ietf.org  Thu May  2 07:32:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13651
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 07:32:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA29343
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 07:32:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26938;
	Thu, 2 May 2002 06:58:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26906
	for <sip@optimus.ietf.org>; Thu, 2 May 2002 06:58:53 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11066
	for <sip@ietf.org>; Thu, 2 May 2002 06:58:49 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g42Awm0E003774;
	Thu, 2 May 2002 12:58:48 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g42Awlkw002845;
	Thu, 2 May 2002 13:58:47 +0300 (EET DST)
Message-ID: <3CD11BE0.36D305A7@lmf.ericsson.se>
Date: Thu, 02 May 2002 13:58:40 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@lucent.com>
CC: sip@ietf.org
Subject: Re: [Sip] Quick WGLC,  Reason draft
References: <019801c1edd5$d541f0d0$1101a8c0@TXDWILLIS2> <3CCD57A9.6070706@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Vijay,

Thanks for the comments. Answers inline:

> Non-nits comments
> -----------------
> 1) The I-D says that:
>     "Initially, the Reason header field defined here appears to be
>      most useful for BYE and CANCEL requests, but it can appear in
>      any request"
> 
>     I seem to recall on the list that the Reason header field was limited
>     to requests within a dialog only.  Is this restriction no longer
>     applicable. 

Yes, it is still applicable. the paragraph now reads as follows:

"Initially, the \header{Reason} header field defined here appears to be
most
useful for {\BYE} and {\CANCEL} requests, but it can appear in any
request within a dialog, in any {\CANCEL} request and in 155 (Update
Requested) responses."

> 2) If I am not mistaken, the ABNF restricts the Reason field to appear
>     only once.  Since it can appear multiple times in a SIP message (and
>     be separable by commas), we should change the ABNF to reflect this.

Yes, I had already received this comment. the BNF now reads:

Reason            & = & "Reason" HCOLON reason-value *(COMMA
reason-value)\\
reason-value      & = & protocol *(SEMI reason-params)\\
protocol          & = & SIP $/$ Q.850 $/$ token\\
[...]

> 
> Nits comments
> -------------
> 1) The ABNF of Reason sets the Protocol field to:
>     Protocol = SIP / Q.850 / token
>     but the paragraph under the ABNF states that the value "SIP/2.0" has
>     been defined for a SIP status code.

This was a copy/paste error. Now it is fixed: SIP is used (rather than
SIP/2.0).

> 2) The following paragraph appears run-on:
>     "When an INVITE is rejected, not because the call is declined,
>     but because some aspect of the request was not acceptable, if
>     the INVITE was forked, the error response is not forwarded
>     towards the UAC by the forking proxy. This problem is known
>     as..."
>     Suggested modifications:
>     "An INVITE can sometimes be rejected not because the session
>     initiation was declined, but becuause some aspect of the request
>     was not acceptable; for instance, if the INVITE forked and
>     resulted in a rejection, which may never be forwarded to the
>     client unless all the other branches also reject the request.
>     This problem is known as ..."

Now it reads as follows:

"An INVITE can sometimes be rejected not because the session initiation
was declined, but because some aspect of the request was not acceptable.
If the INVITE forked and resulted in a rejection, the error response may
never be forwarded to the client unless all the other branches also
reject the request. This problem is known... "

> 
> 3) The four examples in Section 2 correspond roughly to the examples
>     of section 3.  Maybe they should be repeated (or presented for
>     the first time) in the relevant sub-sections of Section 3.

I believe it is alright as it is. It is good to provide examples about
the syntax right after the BNF. The rest of the examples are just call
flows that illustrate a bunch of possible scenarios.

Thanks for your comments,

Gonzalo

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



From daemon@optimus.ietf.org  Thu May  2 08:49:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20107
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 08:49:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA03800
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 08:49:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01824;
	Thu, 2 May 2002 08:18:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01740
	for <sip@optimus.ietf.org>; Thu, 2 May 2002 08:18:24 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17263;
	Thu, 2 May 2002 08:18:16 -0400 (EDT)
Message-Id: <200205021218.IAA17263@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org, sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 02 May 2002 08:18:16 -0400
Subject: [Sip] I-D ACTION:draft-loughney-sip-aaa-req-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIP-AAA Requirements
	Author(s)	: J. Loughney, G. Camarillo
	Filename	: draft-loughney-sip-aaa-req-00.txt
	Pages		: 8
	Date		: 01-May-02
	
As SIP services are deployed on the Internet, there is a need for
authentication, authorization and accounting of SIP sessions.  This
document sets out the basic requirements for this work.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-loughney-sip-aaa-req-00.txt

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

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

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


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

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

--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:	<20020501141411.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-loughney-sip-aaa-req-00.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Thu May  2 08:49:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20125
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 08:49:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA03814
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 08:49:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01927;
	Thu, 2 May 2002 08:18:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01879
	for <sip@optimus.ietf.org>; Thu, 2 May 2002 08:18:49 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17399;
	Thu, 2 May 2002 08:18:43 -0400 (EDT)
Message-Id: <200205021218.IAA17399@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 02 May 2002 08:18:43 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-update-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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 Session Initiation Protocol UPDATE Method
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-update-02.txt
	Pages		: 12
	Date		: 01-May-02
	
This specification defines the new UPDATE method for the Session
Initiation Protocol (SIP). UPDATE allows a client to update
parameters of a session (such as the set of media streams and their
codecs) but has no impact on the state of a dialog. In that sense, it
is like a re-INVITE, but can be sent before the initial INVITE has
completed. This makes it very useful for updating session parameters
within early dialogs.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@ns.ietf.org  Thu May  2 17:54:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12071
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 17:54:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA11368
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 17:54:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10254;
	Thu, 2 May 2002 17:33:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA10173
	for <sip@ns.ietf.org>; Thu, 2 May 2002 17:33:33 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10485;
	Thu, 2 May 2002 17:33:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23018;
	Thu, 2 May 2002 17:32:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA27098;
	Thu, 2 May 2002 17:33:01 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <J79SL9FY>; Thu, 2 May 2002 17:33:00 -0400
Message-ID: <313680C9A886D511A06000204840E1CF030B528B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'sip@ietf.org'" <sip@ietf.org>, "'sipping@ietf.org'"
	 <sipping@ietf.org>
Date: Thu, 2 May 2002 17:32:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Sip] SIP/SIPPING Mail list service may be briefly interrupted
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

They tell me that an upgrade of the software that runs the list
is going to get upgraded.  The current ETA is Tuesday, May 7 from 1 to 3.

Expect a "brief" interruption of service around that time.

Hopefully, brief will be measured in hours, not days :)


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 daemon@ns.ietf.org  Thu May  2 18:50:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17097
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 18:50:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA14553
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:50:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13869;
	Thu, 2 May 2002 18:33:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13799
	for <sip@ns.ietf.org>; Thu, 2 May 2002 18:33:03 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16747
	for <sip@ietf.org>; Thu, 2 May 2002 18:32:59 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW7d04861;
	Thu, 2 May 2002 17:32:07 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, <brian.rosen@marconi.com>,
        <jo@ipdialog.com>, "'Allison Mankin'" <mankin@isi.edu>
Date: Thu, 2 May 2002 17:31:41 -0500
Message-ID: <00ae01c1f229$21b70cf0$1e036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for Replaces header
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I'd like to request Working Group Last Call for the Replaces header.

The current vesion is availabe at:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-01.txt

Or

http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-01.txt

We'd like to clos WGLC by about May 21.

Please copy responses to the list and to Rohan Mahy, who will coordinate
further edits.

--
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 daemon@ns.ietf.org  Thu May  2 18:58:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18505
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 18:58:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA14830
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:58:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13944;
	Thu, 2 May 2002 18:33:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13854
	for <sip@ns.ietf.org>; Thu, 2 May 2002 18:33:08 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16752
	for <sip@ietf.org>; Thu, 2 May 2002 18:33:02 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW8d04869;
	Thu, 2 May 2002 17:32:08 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, "'Allison Mankin'" <mankin@isi.edu>,
        <brian.rosen@cisco.com>, <jo@ipdialog.com>, <rsparks@dynamicsoft.com>
Date: Thu, 2 May 2002 17:31:41 -0500
Message-ID: <00b101c1f229$22ae8c50$1e036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for Refer Draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I'd like to request Working Group Last Call for the REFER method.

The current version is availabe as:

http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-refer-split-00.tx
t

Or

http://search.ietf.org/internet-drafts/draft-sparks-sip-refer-split-00.t
xt


We need to close this by app May 21, so get your comments in. Please
copy the list AND Rober tSparks, who will consolidate responses.

--
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 daemon@ns.ietf.org  Thu May  2 18:58:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18548
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 18:58:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA14859
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:58:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13832;
	Thu, 2 May 2002 18:33:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13790
	for <sip@ns.ietf.org>; Thu, 2 May 2002 18:33:02 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16745
	for <sip@ietf.org>; Thu, 2 May 2002 18:32:58 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW7d04866;
	Thu, 2 May 2002 17:32:07 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "'Allison Mankin'" <mankin@isi.edu>, "'Rohan Mahy'" <rohan@cisco.com>,
        "'Brian Rosen'" <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        "BECKMANN MARK" <mark.beckmann@sal.siemens.de>
Date: Thu, 2 May 2002 17:31:41 -0500
Message-ID: <00b001c1f229$222fbf60$1e036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Expert Review of draft-beckmann-sip-event
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


The SIP Working Group has been requested to provide Expert Review of an
events package for registration state.

The current version is available at:

http://www.softarmor.com/sipwg/drafts/draft-beckmann-sip-reg-event-00.tx
t

Or

http://search.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-00.t
xt


Please copy responses to the list and to Mark Beckmann, who will
coordinate needed edits.

--
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 daemon@ns.ietf.org  Thu May  2 18:58:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18531
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 18:58:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA14845
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 18:58:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13910;
	Thu, 2 May 2002 18:33:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13831
	for <sip@ns.ietf.org>; Thu, 2 May 2002 18:33:06 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16751
	for <sip@ietf.org>; Thu, 2 May 2002 18:33:01 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g42MW7d04860;
	Thu, 2 May 2002 17:32:07 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, <brian.rosen@marconi.com>,
        "'Allison Mankin'" <mankin@isi.edu>, <jo@ipdialog.com>,
        <rsparks@dynamicsoft.com>
Date: Thu, 2 May 2002 17:31:41 -0500
Message-ID: <00af01c1f229$21c1bb50$1e036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC SIP MME Types Registration Draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I'd like to request WGLC of the SIP MIME type registration draft.

The current version can be found at:

http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt

Or

http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt



We'd like to close WGLC by about May 21.

Please copy comments to the list and to Robert Sparks, who will
coordinate further efforts.

--
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 daemon@ns.ietf.org  Thu May  2 22:07:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22074
	for <sip-archive@odin.ietf.org>; Thu, 2 May 2002 22:07:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA23069
	for sip-archive@odin.ietf.org; Thu, 2 May 2002 22:07:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22140;
	Thu, 2 May 2002 21:49:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA22109
	for <sip@ns.ietf.org>; Thu, 2 May 2002 21:49:23 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21893
	for <sip@ietf.org>; Thu, 2 May 2002 21:49:17 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g431mld05926;
	Thu, 2 May 2002 20:48:47 -0500
Message-ID: <005101c1f244$a928dd10$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "Rohan Mahy" <rohan@cisco.com>, <brian.rosen@marconi.com>,
        <jo@ipdialog.com>, <mankin@isi.edu>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>
Date: Thu, 2 May 2002 20:48:44 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC draft-ietf>-sip-dhcpv6
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I'd like to request a working group last call on the DHCP for SIP with
IPv6.

The current version of the draft is available at:

http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt

or


http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-dhcpv6-00.txt

We should try and conclude this by about May 22.

There should be a concurrent last call in the DHC working group.

Thanks,

--
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 daemon@ns.ietf.org  Fri May  3 01:30:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26552
	for <sip-archive@odin.ietf.org>; Fri, 3 May 2002 01:30:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA10234
	for sip-archive@odin.ietf.org; Fri, 3 May 2002 01:30:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08528;
	Fri, 3 May 2002 01:12:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA08446
	for <sip@ns.ietf.org>; Fri, 3 May 2002 01:12:35 -0400 (EDT)
Received: from mailnpd.hcltech.com ([203.197.145.76])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26383
	for <sip@ietf.org>; Fri, 3 May 2002 01:12:20 -0400 (EDT)
Received: from kowsalyapc (kowsalya-pc.hcltech.com [192.168.100.111])
	by mailnpd.hcltech.com (8.11.0/8.11.0) with SMTP id g434uQ905388;
	Fri, 3 May 2002 10:26:28 +0530
Message-ID: <16ee01c1f260$d51a0900$6f64a8c0@hcltech.com>
From: "Kowsalya Subramanian" <kowsalya@npd.hcltech.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, <sip@ietf.org>
References: <3CCF3672.7211E6EF@dynamicsoft.com>
Subject: Re: [Sip] update to UPDATE
Date: Fri, 3 May 2002 10:40:21 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
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
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan,

> The changes:
>
> * excised 155, herfp, reason stuff

I understand that now UPDATE can only be used to update session parameters.
But If the "155 - Update Requested" contains reason-code as one of 401, 416,
420, 423,how will that be handled?

Thanks
Kowsalya



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



From daemon@optimus.ietf.org  Fri May  3 08:00:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10521
	for <sip-archive@odin.ietf.org>; Fri, 3 May 2002 08:00:55 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01031
	for sip-archive@odin.ietf.org; Fri, 3 May 2002 08:00:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28969;
	Fri, 3 May 2002 07:28:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28938
	for <sip@optimus.ietf.org>; Fri, 3 May 2002 07:28:42 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09650;
	Fri, 3 May 2002 07:28:29 -0400 (EDT)
Message-Id: <200205031128.HAA09650@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 03 May 2002 07:28:29 -0400
Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The SIP Access Network Info header
	Author(s)	: D. Mills
	Filename	: draft-mills-sip-access-network-info-01.txt
	Pages		: 5
	Date		: 02-May-02
	
This document defines the private SIP extension header
P-Access-Network-Info. This mechanism is useful in SIP networks that
are partitioned, such as 3G wireless networks which are partitioned at
the SIP layer into 'access' and 'home' networks. SIP User Agents may
use this header to relay information about the access network to
serving proxies in their home network. The serving proxy may then use
this information to optimize services for the UA. For example, a 3GPP
terminal uses this header to pass information about the access network
such as radio access technology and cell ID to its home service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mills-sip-access-network-info-01.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-mills-sip-access-network-info-01.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:	<20020502131627.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-mills-sip-access-network-info-01.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May  3 08:06:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10639
	for <sip-archive@odin.ietf.org>; Fri, 3 May 2002 08:06:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA01473
	for sip-archive@odin.ietf.org; Fri, 3 May 2002 08:06:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28880;
	Fri, 3 May 2002 07:27:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28796
	for <sip@optimus.ietf.org>; Fri, 3 May 2002 07:27:52 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09494;
	Fri, 3 May 2002 07:27:47 -0400 (EDT)
Message-Id: <200205031127.HAA09494@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org, sipping@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 03 May 2002 07:27:47 -0400
Subject: [Sip] I-D ACTION:draft-jennings-sipping-nai-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Extensions to the Session Initiation Protocol (SIP) 
                          for Network Asserted Identity within Trusted Networks
	Author(s)	: C. Jennings
	Filename	: draft-jennings-sipping-nai-00.txt
	Pages		: 14
	Date		: 02-May-02
	
This document describes extensions to SIP that enable a network of
trusted SIP servers to assert the identity of end users or end
systems, and to convey indications of end-user requested privacy.
The use of these extensions are only applicable inside an
administrative domain, or among federations of administrative domains
with previously agreed-upon policies for usage of such information.
This document does NOT offer a general privacy or identity model
suitable for inter-domain use or use in the Internet at large.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jennings-sipping-nai-00.txt

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

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

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


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

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

--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:	<20020502130900.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-jennings-sipping-nai-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-jennings-sipping-nai-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May  3 14:47:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24180
	for <sip-archive@odin.ietf.org>; Fri, 3 May 2002 14:47:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA25137
	for sip-archive@odin.ietf.org; Fri, 3 May 2002 14:47:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23918;
	Fri, 3 May 2002 14:16:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA23876
	for <sip@optimus.ietf.org>; Fri, 3 May 2002 14:16:19 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23086;
	Fri, 3 May 2002 14:16:15 -0400 (EDT)
Message-Id: <200205031816.OAA23086@ietf.org>
To: IETF-Announce: ;
Cc: sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Fri, 03 May 2002 14:16:15 -0400
Subject: [Sip] Last Call: Security Mechanism Agreement for SIP Sessions to
 Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol
Working Group to consider Security Mechanism Agreement for SIP Sessions
<draft-ietf-sip-sec-agree-00.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 any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by May 17, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-sec-agree-00.txt




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



From daemon@optimus.ietf.org  Sat May  4 04:34:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20669
	for <sip-archive@odin.ietf.org>; Sat, 4 May 2002 04:34:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA09453
	for sip-archive@odin.ietf.org; Sat, 4 May 2002 04:34:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08469;
	Sat, 4 May 2002 04:15:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08436
	for <sip@optimus.ietf.org>; Sat, 4 May 2002 04:15:20 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20427
	for <sip@ietf.org>; Sat, 4 May 2002 04:15:15 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g448FI0E015277;
	Sat, 4 May 2002 10:15:18 +0200 (MEST)
Received: from ericsson.com (ppp26.lmf.ericsson.se [131.160.102.26])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g448F9kw011197;
	Sat, 4 May 2002 11:15:16 +0300 (EET DST)
Message-ID: <3CD392C7.2E718D6@ericsson.com>
Date: Sat, 04 May 2002 10:50:31 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: "'Rohan Mahy'" <rohan@cisco.com>
CC: sip@ietf.org
References: <00ae01c1f229$21b70cf0$1e036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Syntax in Replaces
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi:

I've been taking a look at the Replaces-01, and I have a question
regarding the formal syntax. The syntax is defined as:

      Replaces         = "Replaces" HCOLON replaces-values
                          *(COMMA replaces-values)

      replaces-values  = callid *( SEMI replaces-param )
      callid           = token [ "@" token ]
      replaces-param   = to-tag | from-tag | extension-param
      to-tag           = "to-tag" EQUAL ( UUID | "*" )
      from-tag         = "from-tag" EQUAL UUID
      extension-param  = token [ EQUAL ( token | quoted-string ) ]




The question is where is defined the "UUID" that appears in the to-tag
and the from-tag??? I didn't find it in either RFC 2234 nor in RFC 3261?
I guess they should be replaces by a "token".

On the other hand, you seem to re-define "callid", which is already defined
in RFC 3261. For some reason this I-D does not see RFC 3261 when expanding
the ABNF, so I would suggest the following text:

3.2 Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [4] and the Augemented BNF extensions
   defined in section 25 of RFC 3261 [1].

      Replaces         = "Replaces" HCOLON replaces-values
                          *(COMMA replaces-values)

      replaces-values  = callid *( SEMI replaces-param )
      replaces-param   = to-tag | from-tag | extension-param
      to-tag           = "to-tag" EQUAL ( token| "*" )
      from-tag         = "from-tag" EQUAL token
      extension-param  = token [ EQUAL ( token | quoted-string ) ]


As you can see, there is not definition of callid (it is in RFC 3261) and the 
to-tag and from-tag are now tokens.


/Miguel

Dean Willis wrote:
> 
> I'd like to request Working Group Last Call for the Replaces header.
> 
> The current vesion is availabe at:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-01.txt
> 
> Or
> 
> http://search.ietf.org/internet-drafts/draft-ietf-sip-replaces-01.txt
> 
> We'd like to clos WGLC by about May 21.
> 
> Please copy responses to the list and to Rohan Mahy, who will coordinate
> further edits.
> 
> --
> 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

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002



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



From daemon@optimus.ietf.org  Sat May  4 04:35:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20702
	for <sip-archive@odin.ietf.org>; Sat, 4 May 2002 04:35:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA09469
	for sip-archive@odin.ietf.org; Sat, 4 May 2002 04:35:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08507;
	Sat, 4 May 2002 04:15:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08478
	for <sip@optimus.ietf.org>; Sat, 4 May 2002 04:15:54 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20430
	for <sip@ietf.org>; Sat, 4 May 2002 04:15:49 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g448Fos7006659;
	Sat, 4 May 2002 10:15:50 +0200 (MEST)
Received: from ericsson.com (ppp26.lmf.ericsson.se [131.160.102.26])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g448FQkw011206;
	Sat, 4 May 2002 11:15:32 +0300 (EET DST)
Message-ID: <3CD39546.EDE95A68@ericsson.com>
Date: Sat, 04 May 2002 11:01:10 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: sip@ietf.org, Rohan Mahy <rohan@cisco.com>, ehenrikson@LUCENT.COM,
        Keith Drage <drage@LUCENT.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Dialog-ID and Replaces reconciliation
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Eric, Rohan:

The SIP Replaces header and the P-Original-Dialog-ID header seem to 
have some common parts. For instance, both define mechanisms to 
transport the to-tag and the from-tag in the header value.

I was wondering if it would be possible to re-use as much as possible
from the other.

For instance, Replaces defines "to-tag" and "from-tag", whereas
P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think
it would be much better if P-Original-Dialog-ID defines "to-tag" and
"from-tag". The "original-dialog" meaning is implicitely carried 
in the header name and syntax.

This would allow easier definition of the SIP dictionary used in 
compression, because we don't need different entries in the 
dictionary. It would also allow to reuse as much as possible the
software code in an implementation.

On the other hand, Replaces seems to lack a "call-id=" string. 
P-Original-Dialog-ID has it, and it is certainly needed. Is there
a way to synchronize these two??

I hope you can take my comments onboard.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002


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



From daemon@optimus.ietf.org  Sun May  5 10:37:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19325
	for <sip-archive@odin.ietf.org>; Sun, 5 May 2002 10:37:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA19041
	for sip-archive@odin.ietf.org; Sun, 5 May 2002 10:37:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18127;
	Sun, 5 May 2002 10:04:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA18097
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 10:04:29 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18629
	for <sip@ietf.org>; Sun, 5 May 2002 10:04:24 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g45E3wp6005837;
	Sun, 5 May 2002 07:03:58 -0700 (PDT)
Received: from OranLT ([161.44.238.38])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ACV45792;
	Sun, 5 May 2002 07:04:10 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'Drage, Keith \(Keith\)'" <drage@lucent.com>,
        "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'William Marshall'" <wtm@research.att.com>, <sip@ietf.org>
Subject: RE: [Sip] z9hG4bK forever ???
Date: Sun, 5 May 2002 10:03:02 -0400
Organization: Cisco Systems
Message-ID: <017c01c1f43d$9319f9a0$0100a8c0@OranLT>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439E994@en0033exch001u.uk.lucent.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

A light bulb went on...

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of Drage, Keith (Keith)
> Sent: Monday, April 29, 2002 5:26 AM
> To: 'Mark Watson'; 'Dean Willis'; 'William Marshall'; 'sip@ietf.org'
> Subject: RE: [Sip] z9hG4bK forever ???
> 
> 
> The special arragement option depends on how the network 
> operator deals with providing it.
>  
> If the network operator gives it to all and everyone, then it 
> is as you say. Essentially as the From field. This requires 
> no further consideration.
>  
> When it was specified however, one major use was identified 
> as being from enterprise networks, in fact they were the main 
> proponents of such a usage. If one follows the private 
> network ISDN signalling specifications (ISO PSS1 and ECMA 
> QSIG) then enterprise delivered values are screened in the 
> enterprise network, thus as far as the enterprise network is 
> concerned, they are regarded as network asserted rather than 
> as user asserted. The only reason for the special arrangement 
> coding (user provided unscreened) in this case is that the 
> public network operators wanted a distinction between public 
> network asserted identities and private network asserted identities. 
>  
> So far the point is therefore that while enterprise networks 
> can and do assert identities, they may not be fully trusted. 
> In the ISDN, it is trusted sufficiently in order to deliver 
> the CLIP service to the remote user, but is not trusted 
> sufficiently for malicious call identification. If we are to 
> achieve 100% mapping to the ISDN/PSTN, then we may need to 
> reflect this distinction.
>  
Yes, but the ISDN is missing what I believe is a crucial distinction -
whether the NAI was asserted by you (the carrier looking at the SIP
message), or another carrier. The tacit assumption is that the "pubic
networks" comprise a single homogenous trust domain, and everything else
is a "private network" and hence in a different trust domain. There is
no capability for finer granularity nor control of transitivity.

If we simply provide the ability to authenticate the source domain of
the NAI, and to scrub NAI at any boundary between domains, we can
duplicate, as well as improve on the ISDN functionality. If one maps to
ISDN itself, there is clearly some loss of information, as there is with
any mapping function, but this loss is no worse than connecting anything
different to ISDN in the first place.


> I certainly do not believe that we should treat the 
> unscreened coding in all cases as mapping to the From header, 
> as this will not give a 100% mapping in the reverse 
> direction. However, in the longer term, providing some values 
> indicating who provided the assertion may resolve this 
> problem. 
I do not believe anything less than a digitally signed authenticator is
of much use in the world of IP. The attacks are mountable in just about
any envrironment that is not encased in bulletproof walls.

> In this case dummy values such as "non-public 
> network operator" could be used as the asserting identity 
> when such values are mapped.
> 
I am more than a little nervous about introducing native identifiers to
SIP which state nothing meaningful globally from a policy standpoint. I
certainly trust a non-public network operator in the UK to preserve my
privacy more than a pubic network in North Korea. Telling me that an
identity was asserted by a "public network operator" without a digital
signature proving which one it is, does me absolutely no good at all. I
might as well ask for code points like "carrier not cited in last year's
Amnesty International human rights report".

> In the short term, as a large number of public network 
> operators do not allow the special arrangement to exist, it 
> may be best to ignore the special arrangement, or at least 
> the finer details of the mapping.
>  
> Keith
>  
>  
> 
> 	-----Original Message-----
> 	From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> 	Sent: 18 April 2002 12:00
> 	To: 'Dean Willis'; William Marshall; sip@ietf.org
> 	Subject: RE: [Sip] z9hG4bK forever ???
> 	
> 	
> 
> 	I think we're about at the end of this one. 
> 
> 	Two final points from me: 
> 	1) Dean's desire to avoid having the From: field 
> mangled unless he has specifically requested it is 
> reasonable. I still think  that the subscriber's wishes could 
> overrule this though.
> 
> 	This is no different from the ISDN 'Special 
> Arrangement' where the user inserts any number they like in 
> the Calling Party Number field. The network passes it though 
> with no checking, changing, nothing - I think this is 
> analogous to what Dean wants for the From field.
> 
> 	But the network still removes this information if the 
> subscriber wants anonymity. The stated purpose of the field 
> is user identity, which implies Personal Data of the 
> subscriber. This is enough to argue that the network must 
> remove it if privacy is required, and this is certainly the 
> application of current legislation to ISDN.
> 
> 	What is the stated purpose of the From field - I do not 
> think it is sufficiently different for us to be _sure_ that 
> we can avoid the requirement.
> 
> 	So, the munging may still be required, but I certainly 
> agree it should be avoided wherever possible. 
> 
> 	2) In formal terms, 'B2BUA == NOT Proxy'. We all know 
> there will be/are devices which behave very much like a 
> proxy, but perform some additional functions, such as these 
> privacy services. This is fine. Everyone should be aware that 
> with only two terms defined 'B2BUA' and 'Proxy', such devices 
> fall into the B2BUA category.
> 
> 	...Mark 
> 
> 	> -----Original Message----- 
> 	> From: Dean Willis [mailto:dean.willis@softarmor.com] 
> 	> Sent: 17 April 2002 17:36 
> 	> To: William Marshall; sip@ietf.org 
> 	> Subject: Re: [Sip] z9hG4bK forever ??? 
> 	> 
> 	> 
> 	> Baill said: 
> 	> > All this discussion of proxy modification of the From and 
> 	> To headers, 
> 	> > and the need for a B2BUA, seems to me to be a short-term 
> 	> problem only. 
> 	> > 
> 	> > RFC3261 (2543bis-09) specifies matching of 
> dialog-ids based only 
> 	> > on Call-ID and tags, not on display-name or on 
> addr-spec.  So 
> 	> > when all endpoints are compliant with RFC3261, 
> there will be no 
> 	> > problem with a proxy modifying the display-name or 
> addr-spec in 
> 	> > the From header. 
> 	> 
> 	> I disagree. I don't want the network mangling my 
> user-to-user headers 
> 	> unless I've specifically requested it to do so. 
> Specifically, the 
> 	> non-authenticated, non-mangled, non-protected From: field 
> 	> offers utility 
> 	> which is DIFFERENT than that provided by network 
> authenticated calling 
> 	> party ID, and I don't want to sacrifice that utility 
> just because this 
> 	> is a capability the widely-deployed PSTN (as opposed 
> to say Q.SIG) 
> 	> didn't have . . . 
> 	> 
> 	> -- 
> 	> 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 daemon@optimus.ietf.org  Sun May  5 13:09:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21221
	for <sip-archive@odin.ietf.org>; Sun, 5 May 2002 13:09:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA25024
	for sip-archive@odin.ietf.org; Sun, 5 May 2002 13:09:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24196;
	Sun, 5 May 2002 12:49:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24160
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 12:49:16 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21089
	for <sip@ietf.org>; Sun, 5 May 2002 12:49:09 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g45Gmjp6011498
	for <sip@ietf.org>; Sun, 5 May 2002 09:48:45 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACV46303;
	Sun, 5 May 2002 09:48:58 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <sip@ietf.org>
Date: Sun, 5 May 2002 09:48:54 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCOEAHCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Digest auth-int in bis9
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I interpret lines 4997-5001 in bis9 say that a bis 9 proxy must set the qop
parameter in a challenge and a bis 9 compliant UA must also set them in the
reply to the challenge.

It is not clear if the proxy or UA must do auth or auth-int. The example
shows the proxy being able to do both and the UA selecting just auth. I
think we should make it clear what the preferred thing for a UA to do.

The point I am getting to is, if the UA selects auth-int and sends it
through a SIP ALG firewall/nat, odd are good that the SDP gets modified and
when the proxy gets the message it will fail the auth-int check. I don't
know if this is a feature or a bug but it seems worth explicitly discussing.
When we want to protect bodies, I think there are much better approaches
than Digest auth-int.

My proposal is that User Agents are RECOMMENDED NOT to use auth-int and that
Proxies MAY support auth-int but MUST support auth.

Thoughts?

Cullen


PS. Is there any reason why RFC 2617 has auth quoted in WWW-Authenticate
header but not quoted in a Authorization header?





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



From daemon@optimus.ietf.org  Sun May  5 15:33:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22549
	for <sip-archive@odin.ietf.org>; Sun, 5 May 2002 15:33:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA00138
	for sip-archive@odin.ietf.org; Sun, 5 May 2002 15:33:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29277;
	Sun, 5 May 2002 15:13:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29248
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 15:13:24 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22383
	for <sip@ietf.org>; Sun, 5 May 2002 15:13:18 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g45JDgn19371
	for <sip@ietf.org>; Sun, 5 May 2002 22:13:42 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5aaf1a6f57ac158f2211e@esvir02nok.ntc.nokia.com>;
 Sun, 5 May 2002 22:13:21 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Sun, 5 May 2002 22:13:21 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] Digest auth-int in bis9
Date: Sun, 5 May 2002 22:13:21 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FECF9@esebe013.NOE.Nokia.com>
Thread-Topic: [Sip] Digest auth-int in bis9
Thread-Index: AcH0VOX82qNkS8yBQUu2oA2C0fQ/RgAEeRiw
To: <sip@ietf.org>
Cc: <fluffy@cisco.com>
X-OriginalArrivalTime: 05 May 2002 19:13:21.0815 (UTC) FILETIME=[EC1C7A70:01C1F468]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA29249
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi Cullen,

> I interpret lines 4997-5001 in bis9 say that a bis 9 proxy 
> must set the qop
> parameter in a challenge and a bis 9 compliant UA must also 
> set them in the
> reply to the challenge.

I assume that the reason for this is that bis-9 compatible proxies and UAs need not be RFC2069 compatible, which is why in RFC2617, the qop is optional.
 
> It is not clear if the proxy or UA must do auth or auth-int. 
> The example
> shows the proxy being able to do both and the UA selecting 
> just auth. I
> think we should make it clear what the preferred thing for a UA to do.

This depends on the application, so I don't think such an explicit preference exists. For example, to a REGISTER or MESSAGE, auth-int could make more sense than when proxy-authenticating an INVITE...

> The point I am getting to is, if the UA selects auth-int and sends it
> through a SIP ALG firewall/nat, odd are good that the SDP 
> gets modified and
> when the proxy gets the message it will fail the auth-int 
> check. I don't
> know if this is a feature or a bug but it seems worth 
> explicitly discussing.
> When we want to protect bodies, I think there are much better 
> approaches
> than Digest auth-int.

Auth-int seems like a very easy and inexpensive way to protect bodies, and headers as well by using sip-frag. You are right that an ALG that modifies the SDP will fail the auth-int authentication. But it will also fail S/MIME or any other integrity protection on the body.

> 
> My proposal is that User Agents are RECOMMENDED NOT to use 
> auth-int and that
> Proxies MAY support auth-int but MUST support auth.
> 
> Thoughts?

I don't agree. Auth-int is useful in some authentication scenarios, just not when there is a firewall/NAT that modifies the message bodies.

> PS. Is there any reason why RFC 2617 has auth quoted in 
> WWW-Authenticate
> header but not quoted in a Authorization header?

In WWW-Authenticate, its a comma separated list, whereas in Authorization it's a token.

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 daemon@optimus.ietf.org  Sun May  5 16:38:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23200
	for <sip-archive@odin.ietf.org>; Sun, 5 May 2002 16:38:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA02083
	for sip-archive@odin.ietf.org; Sun, 5 May 2002 16:38:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01224;
	Sun, 5 May 2002 16:12:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01193
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 16:12:12 -0400 (EDT)
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23051
	for <sip@ietf.org>; Sun, 5 May 2002 16:12:06 -0400 (EDT)
Received: from there (kevlar.softarmor.com [127.0.0.1])
	by kevlar.softarmor.com (8.11.6/8.11.6) with SMTP id g45KBFn09583;
	Sun, 5 May 2002 15:11:16 -0500
Message-Id: <200205052011.g45KBFn09583@kevlar.softarmor.com>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Dean Willis <dean.willis@softarmor.com>
To: "Tan Ya-Ching  ICM N PG U ID A 1" <Ya-Ching.Tan@icn.siemens.de>,
        "'Dean Willis'" <dwillis@dynamicsoft.com>, <sip@ietf.org>,
        "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>
Subject: Re: [Sip] Revised Path draft (-04) submitted
Date: Sun, 5 May 2002 15:11:15 -0500
X-Mailer: KMail [version 1.3.2]
Cc: <bernhard.honeisen@nokia.com>, <amankin@isi.edu>,
        "'Rohan Mahy'" <rohan@cisco.com>, <jo@ipdialog.com>,
        <brian.rosen@marconi.com>
References: <5B4D0C5BA65ECA46969C1419122317E6E74D80@mchh161e>
In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E6E74D80@mchh161e>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

On Tuesday 30 April 2002 04:19 am, Tan Ya-Ching  ICM N PG U ID A 1 wrote:
> Dean,
>
> Just nits:
>
> - The first line of Path in Table 3 should have a "o" under REG.


Once again, I find these tables confusing.  The bis draft says:

   "Optional" means that a UA MAY include the header field in a request
   or response, and a UA MAY ignore the header field if present in the
   request or response (The exception to this rule is the Require header
   field discussed in 20.32). A "mandatory" header field MUST be present
   in a request, and MUST be understood by the UAS receiving the
   request. A mandatory response header field MUST be present in the
   response, and the header field MUST be understood by the UAC
   processing the response. "Not applicable" means that the header field
   MUST NOT be present in a request. If one is placed in a request by
   mistake, it MUST be ignored by the UAS receiving the request.
   Similarly, a header field labeled "not applicable" for a response
   means that the UAS MUST NOT place the header field in the response,
   and the UAC MUST ignore the header field in the response.

I think you're suggesting that the Table 2/3 entry for Path should have an O 
for the  value representing its applicability in a registration request as 
generated by the UA.  At least, that's what I think putting an O there means.

I don't believe this is what we want. The UA MUST NOT insert a Path header in 
its registration request. Proxies may add one or append to one inserted by 
another proxy.

So how do the rest of you read this table?

--
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 daemon@optimus.ietf.org  Sun May  5 16:38:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23217
	for <sip-archive@odin.ietf.org>; Sun, 5 May 2002 16:38:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA02097
	for sip-archive@odin.ietf.org; Sun, 5 May 2002 16:38:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01411;
	Sun, 5 May 2002 16:22:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01382
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 16:22:32 -0400 (EDT)
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23100
	for <sip@ietf.org>; Sun, 5 May 2002 16:22:26 -0400 (EDT)
Received: from there (kevlar.softarmor.com [127.0.0.1])
	by kevlar.softarmor.com (8.11.6/8.11.6) with SMTP id g45KLwn09616;
	Sun, 5 May 2002 15:21:58 -0500
Message-Id: <200205052021.g45KLwn09616@kevlar.softarmor.com>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Dean Willis <dean.willis@softarmor.com>
To: "Finnie, Donald" <donald.finnie@intel.com>, <sip@ietf.org>
Date: Sun, 5 May 2002 15:21:57 -0500
X-Mailer: KMail [version 1.3.2]
Cc: <dwillis@dynamicsoft.com>, <bernhard.honeisen@nokia.com>
References: <9985493A802AD5118C4E009027462753015CF89B@swsmsx34.isw.intel.com>
In-Reply-To: <9985493A802AD5118C4E009027462753015CF89B@swsmsx34.isw.intel.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Sip] Re: Comments on draft-willis-sip-path-04
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

On Wednesday 01 May 2002 11:25 am, Finnie, Donald wrote:
> Section 2. "Applicability Statement" seems to have some ambiguous wording
> in
> my opinion.
>
> 2.2 says "One or more of the intermediate proxies MUST be visited by
> messages between REGISTRAR and UA."
>
> The use of the words "between" and "messages" seem ambiguous.  I assume
> this
> refers only to dialog-initiating messages sent *from* REGISTRAR *to* UA?
> If
> my understanding of the Path mechanism is correct, it does not effect
> INVITE
> messages, for example, sent from UA to some target via REGISTRAR/home
> service proxy.  Nor does it imply Record-Routing at intermediate proxies
> so
> they will only remain in the signalling path if they choose to
> Record-Route.

The applicability statement says messages because it means" all messages, not 
just dialog-inititaing messages and replies". SIP gives us mechanisms (Via 
and Record-Route) to force replies subsequent messages in a dialog to 
traverse the route of the original message.  We also have a mechanism (the 
preloaded Route)  which allows us to force an out-of-dialog request to visit 
certain nodes. What we don't have is a way to tell the UA what Route to 
pre-load (P-Service-Route) or a way to tell a retargeting proxy what Route to 
add in order to reach a Contact that once must reach through a specific route.

Specifically, Path is applied to any SIP request (not just a dialog 
initiating message) originating at or traversing the retargetting proxy 
associated with the registrar.

I'll see if I can clarify this slightly in the next revision.

>
>
> 2.2 says "The same set of proxies must be visited by messages between a
> home
> service proxy and UA.  That is,  the proxy route between  the UA and its
> home service proxy is identical to the proxy route between the UA and its
> registrar."
>
> The Path mechanism only forces this situation for incoming messages
> arriving
> at the registrar/home service proxy destined to the UA. Correct?

Yes. Other techniques meet other requirements in the applicability statement.

--
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 daemon@optimus.ietf.org  Sun May  5 17:23:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23770
	for <sip-archive@odin.ietf.org>; Sun, 5 May 2002 17:23:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA03963
	for sip-archive@odin.ietf.org; Sun, 5 May 2002 17:23:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03736;
	Sun, 5 May 2002 17:07:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03705
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 17:07:34 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23611
	for <sip@ietf.org>; Sun, 5 May 2002 17:07:27 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g45L72d01951;
	Sun, 5 May 2002 16:07:02 -0500
Message-ID: <002301c1f478$b385d570$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        <bernhard.honeisen@nokia.com>, "Rohan Mahy" <rohan@cisco.com>,
        <brian.rosen@marconi.com>, <jo@ipdialog.com>
Date: Sun, 5 May 2002 16:06:18 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for draft-willis-sip-path-05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I'd like to request Working Group Last Call for draft-willis-sip-path.
This will need to close by about 11May.

Version -05 draft has been submitted to internet-drafts and shoudl be
available.

in the meantime use:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt

or

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html


--
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 daemon@optimus.ietf.org  Mon May  6 03:04:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09072
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 03:04:30 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA01493
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 03:04:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00302;
	Mon, 6 May 2002 02:35:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA00266
	for <sip@optimus.ietf.org>; Mon, 6 May 2002 02:35:46 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08768
	for <sip@ietf.org>; Mon, 6 May 2002 02:35:39 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g466Za0E010396;
	Mon, 6 May 2002 08:35:37 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g466Za9q025210;
	Mon, 6 May 2002 09:35:36 +0300 (EET DST)
Message-ID: <3CD62433.C1714CB@ericsson.com>
Date: Mon, 06 May 2002 09:35:31 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Dean Willis <dean.willis@SOFTARMOR.COM>
CC: 3GPP_TSG_CN_WG1@LIST.ETSI.FR, sip@ietf.org, bernhard.honeisen@nokia.com
References: <002301c1f478$b385d570$133fed0c@C1893415A>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: WGLC for draft-willis-sip-path-05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Dean, Bernie:

Some comments to the Path header, mostly NITS.

1) Regarding the tag option "Path" for the Supported header, as far as 
   I have seen before, most of the other option tags are defined in 
   lowercase. I would suggest to follow the same approach for consistency,
   that is, define "path".

2) The syntax defined at the end of section 3 does not allow the Path 
   header to be part of the request, only to the response. I suspect 
   this is an error. Suggestion:

         Header field          where   proxy ACK BYE CAN INV OPT REG PRA
         _______________________________________________________________
         Path                    R       ar   -   -   -   -   -   o   -
         Path                   2xx       -   -   -   -   -   -   o   -

3) The last sentence in section 4.1 reads: "The UA should include the
   option tag 'Path' in any Supported headers". I suspect this inclusion
   affects all the instances of Supported, including those in an INVITE.
   Can you confirm this?

4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be
   replaced by reference [2] (bis-09).

5) In section 4.7, the Via in the examples do not begin with "z9hG4bK"
   as required by bis-09.

Thanks a lot,

       Miguel


Dean Willis wrote:
> 
> I'd like to request Working Group Last Call for draft-willis-sip-path.
> This will need to close by about 11May.
> 
> Version -05 draft has been submitted to internet-drafts and shoudl be
> available.
> 
> in the meantime use:
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt
> 
> or
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html
> 
> --
> Dean

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Mon May  6 04:44:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09914
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 04:44:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA05499
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 04:44:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03713;
	Mon, 6 May 2002 04:03:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03682
	for <sip@optimus.ietf.org>; Mon, 6 May 2002 04:03:37 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09589
	for <sip@ietf.org>; Mon, 6 May 2002 04:03:31 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.15])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4684PLC014055;
	Mon, 6 May 2002 04:04:27 -0400 (EDT)
Message-ID: <3CD638B2.77B305B7@dynamicsoft.com>
Date: Mon, 06 May 2002 04:02:58 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kowsalya Subramanian <kowsalya@npd.hcltech.com>
CC: sip@ietf.org
Subject: Re: [Sip] update to UPDATE
References: <16ee01c1f260$d51a0900$6f64a8c0@hcltech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Kowsalya Subramanian wrote:
> 
> Jonathan,
> 
> > The changes:
> >
> > * excised 155, herfp, reason stuff
> 
> I understand that now UPDATE can only be used to update session
> parameters.
> But If the "155 - Update Requested" contains reason-code as one of 401,
> 416,
> 420, 423,how will that be handled?

An extension will specify how to use UPDATE to handle this case. That
extension will define the 155 response code as well.

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Mon May  6 04:45:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09948
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 04:45:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA05545
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 04:45:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03826;
	Mon, 6 May 2002 04:06:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03794
	for <sip@optimus.ietf.org>; Mon, 6 May 2002 04:06:26 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09596
	for <sip@ietf.org>; Mon, 6 May 2002 04:06:20 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 174dVb-00085s-00; Mon, 06 May 2002 11:06:11 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15574.14707.901024.844778@harjus.eng.song.fi>
Date: Mon, 6 May 2002 11:06:11 +0300
To: "Dean Willis" <dean.willis@softarmor.com>
Cc: <sip@ietf.org>, "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        <bernhard.honeisen@nokia.com>, "Rohan Mahy" <rohan@cisco.com>,
        <brian.rosen@marconi.com>, <jo@ipdialog.com>
Subject: [Sip] WGLC for draft-willis-sip-path-05
In-Reply-To: <002301c1f478$b385d570$133fed0c@C1893415A>
References: <002301c1f478$b385d570$133fed0c@C1893415A>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

below are my comments:

- i thought that it was agreed to use name rrr instead of path for this
  header.  the reason is that this header is both semantically and
  syntactically very close to record-route.  also, name path is not at
  all descriptive, what path?

- this paragraph should be moved, since somebody's suggestions regarding
  things that are outside the scope of the i-d should not be part of
  the normative text:

  It has been suggested that the UA MAY choose to store the contents of
  the Path header for future use as a preloaded Route for use when the
  UA wishes to send a SIP message that, for reasons of acquiring
  services in the home network, need to transit the service proxies in
  the home network.  Such usage is explicitly outside the scope of this
  document.

-- 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 daemon@optimus.ietf.org  Mon May  6 07:50:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13726
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 07:50:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA13994
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 07:50:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12731;
	Mon, 6 May 2002 07:26:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12700
	for <sip@optimus.ietf.org>; Mon, 6 May 2002 07:26:03 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12977;
	Mon, 6 May 2002 07:25:55 -0400 (EDT)
Message-Id: <200205061125.HAA12977@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 06 May 2002 07:25:54 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-call-auth-05.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: SIP Extensions for Media Authorization
	Author(s)	: W. Marshall, F. Andreasen, D. Evans
	Filename	: draft-ietf-sip-call-auth-05.txt
	Pages		: 13
	Date		: 03-May-02
	
This document describes the need for QoS and media authorization and 
defines a SIP extension that can be used to integrate QoS admission 
control with call signaling and help guard against denial of service 
attacks. The use of this extension is only applicable in administrative 
domains, or among federations of administrative domains with previously 
agreed-upon policies, where both the SIP proxy authorizing the QoS, and 
the policy control of the underlying network providing the QoS belong to 
that administrative domain or federation of domains.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-call-auth-05.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@ns.ietf.org  Mon May  6 11:56:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24536
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 11:56:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA00314
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 11:56:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28280;
	Mon, 6 May 2002 11:21:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA28249
	for <sip@ns.ietf.org>; Mon, 6 May 2002 11:21:45 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23520
	for <sip@ietf.org>; Mon, 6 May 2002 11:21:38 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g46FLRs7024166;
	Mon, 6 May 2002 17:21:27 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g46FLQ9q000963;
	Mon, 6 May 2002 18:21:26 +0300 (EET DST)
Message-ID: <3CD69F6F.A1F17163@ericsson.com>
Date: Mon, 06 May 2002 18:21:19 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: jh@lohi.eng.song.fi
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org,
        3GPP_TSG_CN_WG1 <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        bernhard.honeisen@nokia.com, Rohan Mahy <rohan@cisco.com>,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] WGLC for draft-willis-sip-path-05
References: <002301c1f478$b385d570$133fed0c@C1893415A> <15574.14707.901024.844778@harjus.eng.song.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Juha:

I believe the name of the header should be related as much as possible to 
the semantics, not to the relation with other headers and how to build it.

Therefore, having a name of a header "rrr" sounds to me like coding ISUP.
I would prefer to keep the name Path as it is suggested in the draft.

/Miguel

jh@lohi.eng.song.fi wrote:
> 
> below are my comments:
> 
> - i thought that it was agreed to use name rrr instead of path for this
>   header.  the reason is that this header is both semantically and
>   syntactically very close to record-route.  also, name path is not at
>   all descriptive, what path?
> 
> - this paragraph should be moved, since somebody's suggestions regarding
>   things that are outside the scope of the i-d should not be part of
>   the normative text:
> 
>   It has been suggested that the UA MAY choose to store the contents of
>   the Path header for future use as a preloaded Route for use when the
>   UA wishes to send a SIP message that, for reasons of acquiring
>   services in the home network, need to transit the service proxies in
>   the home network.  Such usage is explicitly outside the scope of this
>   document.
> 
> -- 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

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@ns.ietf.org  Mon May  6 12:16:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25278
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 12:16:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA02753
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 12:16:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29871;
	Mon, 6 May 2002 11:46:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29840
	for <sip@ns.ietf.org>; Mon, 6 May 2002 11:46:20 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24293
	for <sip@ietf.org>; Mon, 6 May 2002 11:46:13 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g46FjmL16519;
	Mon, 6 May 2002 11:45:48 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA13569; Mon, 6 May 2002 10:45:48 -0500 (CDT)
Message-ID: <3CD6A51F.1020600@lucent.com>
Date: Mon, 06 May 2002 10:45:35 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org
Subject: Re: [Sip] WGLC for draft-willis-sip-path-05
References: <002301c1f478$b385d570$133fed0c@C1893415A>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Dean Willis wrote:
> I'd like to request Working Group Last Call for draft-willis-sip-path.
> This will need to close by about 11May.
> 
> Version -05 draft has been submitted to internet-drafts and shoudl be
> available.
[...]

Dean:

New comments based on -05 I-D:
Section 4.2, first paragraph: s/future transmissions/future transactions

Old comments, persisting from -04 I-D:

Section 1, "UA" still remains in the figure, although the succeeding
text refers to "UA1".  To remain consistent with later figures, change
"UA" in Section 1 figure to "UA1".

I also made a general comment in the last review round, which may have
escaped your attention; I reproduce the comment here (full context can
be found at
http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04979.html)

vkg> Generally speaking, in many places where you use "message", I
vkg> believe you mean "requests".  If so, can we substitute the
vkg> term request, since a "message" may be a response, for
vkg> instance, which will follow the Via paths.

dean>Reasonable.

vkg> In Section 4.6, the requests from P1->P2 show P1 adding
vkg> itself to the Path list (initially set to null).  The branch
vkg> of P1 does NOT contain the "magic cookie" (z9hG4bK).
vkg> Likewise for P3->REGISTRAR. Since P1 and P3 supports "lr", it
vkg> is a good bet that they also support the Via "magic cookie".
vkg> Of course, this is an obscure nit, but all the same...

dean> Good point.

It appears that you have added the magic cookie to in the UA1->P1
INVITE request, which is okay, since UA1 supports lr, so there-
fore it also supports the new Via "magic cookie".  But so do proxies P1
and P3; however, the Vias for P1 and P3 do not contain the magic cookie.
Again, this is a pedantic nit, so I will leave it at your discretion
on what to do.  I resurrect this here based solely on your modification
of the UA1->P1 INVITE request to add the magic cookie.

That's all!

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216


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



From daemon@ns.ietf.org  Mon May  6 15:07:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03274
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 15:07:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA13515
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 15:07:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11726;
	Mon, 6 May 2002 14:37:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11689
	for <sip@ns.ietf.org>; Mon, 6 May 2002 14:37:18 -0400 (EDT)
Received: from fox.iptel.org (fox.iptel.org [195.37.77.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02030
	for <sip@ietf.org>; Mon, 6 May 2002 14:37:10 -0400 (EDT)
Received: from jku2.fokus.gmd.de (port-213-20-128-170.reverse.qdsl-home.de [213.20.128.170])
	by fox.iptel.org (8.11.6/8.11.6) with ESMTP id g46Id7W05957
	for <sip@ietf.org>; Mon, 6 May 2002 20:39:07 +0200
Message-Id: <5.1.0.14.0.20020506145829.01fa7170@mailhost.fokus.gmd.de>
X-Sender: jku@mailhost.fokus.gmd.de
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 06 May 2002 15:00:50 +0200
To: sip@ietf.org
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Subject: Interop Issue (was Fwd: [Sip] REGISTER Processing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

[Resent -- this was a bis-09 interop issue at the last sip-it and I am
surprised not to have seen any reply on it from any of bis authors.]


>There seems to be insufficient guidance in bis-09 on usage of Call-ID
>in REGISTERs. The only thing which I found there is in 10.2.4:
>
>  "A UA SHOULD use the same Call-ID for all registrations during a
>   single boot cycle. "
>
>I think that does NOT require Call-ID to change across reboots. UAs
>with no memory are not explicitely mandated to change Call-ID (ignoring
>that bis asks to deny REGISTERs with Call-ID== and CSeq <= values in registrar's
>bindings). If the UACs actually do not change Call-ID, REGISTERs after reboots 
>with low CSeq will be ignored.
>
>Which actually happened during two tests in SIPIt.
>
>Also the SHOULD strengh seems to weak -- 'SHOULD' MUST be used if
>not doing so does not break things, which is not the case here.
>
>--
>
>Other confusing thing is which SIP reply a request failure for out-of-order REGISTERs 
>in line 1740 implies. I could connect it to the next paragraph "....if binding 
>update fails...the request MUST fail with 500..." but I am not sure that 500 is 
>a good choice.
>
>--
>
>Yet anothet thing, which Jan pointed out, is that handling of out-or-order
>in lines 1738-40 also includes retransmissions (CSeq and CallID in request and
>bindings equal). Sending some negative reply upstream would in that case 
>cause the upstream UAC to consider registration failed.
>
>-Jiri


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



From daemon@ns.ietf.org  Mon May  6 15:26:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03643
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 15:26:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA14139
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 15:26:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12450;
	Mon, 6 May 2002 14:53:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12418
	for <sip@ns.ietf.org>; Mon, 6 May 2002 14:52:58 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02790
	for <sip@ietf.org>; Mon, 6 May 2002 14:52:50 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g46Iptq05697;
	Mon, 6 May 2002 13:51:55 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXXMRM2>; Mon, 6 May 2002 13:52:03 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B05F@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>,
        Dean Willis
	 <dean.willis@SOFTARMOR.COM>
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR, sip@ietf.org, bernhard.honeisen@nokia.com
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Mon, 6 May 2002 13:51:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F52F.191B1D80"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1F52F.191B1D80
Content-Type: text/plain;
	charset="iso-8859-1"

Dean, Bernie,

One more recommendation:

** Since the draft adds an option tag "path". I would highly recommend that
put "Supported:path,...." in all REGISTER's shown in the draft.

Thanks,

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


-----Original Message-----
From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
Sent: Monday, May 06, 2002 1:36 AM
To: Dean Willis
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;
bernhard.honeisen@nokia.com
Subject: [Sip] Re: WGLC for draft-willis-sip-path-05


Dean, Bernie:

Some comments to the Path header, mostly NITS.

1) Regarding the tag option "Path" for the Supported header, as far as 
   I have seen before, most of the other option tags are defined in 
   lowercase. I would suggest to follow the same approach for consistency,
   that is, define "path".

2) The syntax defined at the end of section 3 does not allow the Path 
   header to be part of the request, only to the response. I suspect 
   this is an error. Suggestion:

         Header field          where   proxy ACK BYE CAN INV OPT REG PRA
         _______________________________________________________________
         Path                    R       ar   -   -   -   -   -   o   -
         Path                   2xx       -   -   -   -   -   -   o   -

3) The last sentence in section 4.1 reads: "The UA should include the
   option tag 'Path' in any Supported headers". I suspect this inclusion
   affects all the instances of Supported, including those in an INVITE.
   Can you confirm this?

4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be
   replaced by reference [2] (bis-09).

5) In section 4.7, the Via in the examples do not begin with "z9hG4bK"
   as required by bis-09.

Thanks a lot,

       Miguel


Dean Willis wrote:
> 
> I'd like to request Working Group Last Call for draft-willis-sip-path.
> This will need to close by about 11May.
> 
> Version -05 draft has been submitted to internet-drafts and shoudl be
> available.
> 
> in the meantime use:
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt
> 
> or
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html
> 
> --
> Dean

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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_01C1F52F.191B1D80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Sip] Re: WGLC for draft-willis-sip-path-05</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dean, Bernie,</FONT>
</P>

<P><FONT SIZE=3D2>One more recommendation:</FONT>
</P>

<P><FONT SIZE=3D2>** Since the draft adds an option tag =
&quot;path&quot;. I would highly recommend that put =
&quot;Supported:path,....&quot; in all REGISTER's shown in the =
draft.</FONT></P>

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

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Miguel A. Garcia [<A =
HREF=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@eric=
sson.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, May 06, 2002 1:36 AM</FONT>
<BR><FONT SIZE=3D2>To: Dean Willis</FONT>
<BR><FONT SIZE=3D2>Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; =
sip@ietf.org;</FONT>
<BR><FONT SIZE=3D2>bernhard.honeisen@nokia.com</FONT>
<BR><FONT SIZE=3D2>Subject: [Sip] Re: WGLC for =
draft-willis-sip-path-05</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Dean, Bernie:</FONT>
</P>

<P><FONT SIZE=3D2>Some comments to the Path header, mostly NITS.</FONT>
</P>

<P><FONT SIZE=3D2>1) Regarding the tag option &quot;Path&quot; for the =
Supported header, as far as </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; I have seen before, most of the other =
option tags are defined in </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; lowercase. I would suggest to follow =
the same approach for consistency,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; that is, define =
&quot;path&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>2) The syntax defined at the end of section 3 does =
not allow the Path </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; header to be part of the request, only =
to the response. I suspect </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; this is an error. Suggestion:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Header field&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
where&nbsp;&nbsp; proxy ACK BYE CAN INV OPT REG PRA</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
_______________________________________________________________</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Path&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ar&nbsp;&nbsp; -&nbsp;&nbsp; =
-&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; o&nbsp;&nbsp; =
-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Path&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
2xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; =
-&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; o&nbsp;&nbsp; =
-</FONT>
</P>

<P><FONT SIZE=3D2>3) The last sentence in section 4.1 reads: &quot;The =
UA should include the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; option tag 'Path' in any Supported =
headers&quot;. I suspect this inclusion</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; affects all the instances of Supported, =
including those in an INVITE.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Can you confirm this?</FONT>
</P>

<P><FONT SIZE=3D2>4) Reference 1 (RFC 2543) and to &quot;the =
binding&quot; (section 4.3) should be</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; replaced by reference [2] =
(bis-09).</FONT>
</P>

<P><FONT SIZE=3D2>5) In section 4.7, the Via in the examples do not =
begin with &quot;z9hG4bK&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; as required by bis-09.</FONT>
</P>

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

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

<P><FONT SIZE=3D2>Dean Willis wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'd like to request Working Group Last Call for =
draft-willis-sip-path.</FONT>
<BR><FONT SIZE=3D2>&gt; This will need to close by about 11May.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Version -05 draft has been submitted to =
internet-drafts and shoudl be</FONT>
<BR><FONT SIZE=3D2>&gt; available.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; in the meantime use:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.t=
xt" =
TARGET=3D"_blank">http://www.softarmor.com/sipwg/drafts/draft-willis-sip=
-path-05.txt</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; or</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.h=
tml" =
TARGET=3D"_blank">http://www.softarmor.com/sipwg/drafts/draft-willis-sip=
-path-05.html</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Dean</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Miguel-Angel =
Garcia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Oy LM Ericsson =
AB</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; Jorvas, Finland</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@eric=
sson.com</A>&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp; +358 9 299 =
3553</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"mailto:Miguel.A.Garcia@piuha.net">mailto:Miguel.A.Garcia@piuha.n=
et</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile: +358 40 =
5140002</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>This list is for NEW development of the core SIP =
Protocol</FONT>
<BR><FONT SIZE=3D2>Use sip-implementors@cs.columbia.edu for questions =
on current sip</FONT>
<BR><FONT SIZE=3D2>Use sipping@ietf.org for new developments on the =
application of sip</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F52F.191B1D80--

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



From daemon@ns.ietf.org  Mon May  6 21:41:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13319
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 21:41:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA09076
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 21:41:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07611;
	Mon, 6 May 2002 21:20:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21483
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 11:42:24 -0400 (EDT)
Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20300
	for <sip@ietf.org>; Sun, 5 May 2002 11:42:17 -0400 (EDT)
Received: from nt-mail.radvision.com ([212.143.185.30])
 by mxout1.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep  5 2001))
 with ESMTP id <0GVN00854A9KMO@mxout1.netvision.net.il> for sip@ietf.org; Sun,
 05 May 2002 18:41:44 +0300 (IDT)
Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2650.21)
	id <KJ7L2T6K>; Sun, 05 May 2002 18:40:13 +0300
Content-return: allowed
Date: Sun, 05 May 2002 18:40:12 +0300
From: Itamar Gilad <ItamarG@radvision.com>
To: SIP list <sip@ietf.org>
Cc: Adi Even-Tzur <adie@radvision.com>
Message-id: <EE5AF23B5764D511A6B900508BB82A0B1B1AD2@nt-mail.radvision.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=WINDOWS-1255
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Subject: [Sip] To-tag in REGISTER
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

This is question we ran into in the last SIPit. How should an incoming
REGISTER request be handled if it has a To tag:

1. Reject the request with a 4xx response code (Invalid Registration)
or 
2. Accept the request but ignore the To tag at the address-of-record stored
at the location DB (the record is stored without the tag).

Thanks in advance

  Itamar Gilad
  RADVISION



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



From daemon@ns.ietf.org  Mon May  6 21:41:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13356
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 21:41:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA09091
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 21:41:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07615;
	Mon, 6 May 2002 21:20:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03554
	for <sip@optimus.ietf.org>; Sun, 5 May 2002 17:01:21 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23546
	for <sip@ietf.org>; Sun, 5 May 2002 17:01:14 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g45L0nd01807;
	Sun, 5 May 2002 16:00:50 -0500
Message-ID: <001101c1f477$d52a0170$133fed0c@C1893415A>
From: "Dean Willis" <dwillis@greycouncil.com>
To: <sip@ietf.org>
Cc: <bernhard.honeisen@nokia.com>,
        "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>
Date: Sun, 5 May 2002 16:00:05 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-willis-sip-svcrtdisco-03 now available
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

This draft has been submitted to internet-drafts and should appear
shortly.

In the meantime, use:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-03.txt
OR
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-03.htm
l

Please recall that this draft is cureently under Expert Review. Get
those comments in please!

--
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 daemon@ns.ietf.org  Mon May  6 21:46:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14498
	for <sip-archive@odin.ietf.org>; Mon, 6 May 2002 21:46:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA10013
	for sip-archive@odin.ietf.org; Mon, 6 May 2002 21:46:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07642;
	Mon, 6 May 2002 21:20:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08654
	for <sip@ns.ietf.org>; Mon, 6 May 2002 13:56:17 -0400 (EDT)
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29684
	for <sip@ietf.org>; Mon, 6 May 2002 13:56:10 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g46Htkk12203
	for <sip@ietf.org>; Mon, 6 May 2002 13:55:46 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21)
	id <KG75T1W7>; Mon, 6 May 2002 12:55:45 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C026055B5@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>, sip@ietf.org,
        Rohan Mahy <rohan@cisco.com>,
        "Drage, Keith (Keith)" <drage@lucent.com>
Date: Mon, 6 May 2002 12:55:42 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [Sip] RE: Dialog-ID and Replaces reconciliation
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Miguel, Rohan,

I took a look at the Replaces header and I see some similarities.  However,
I don't think I'm going to have time today to rework the syntax and submit
all my 3GPP contributions.  So I think this will have to wait until later
this week.

Eric

-----Original Message-----
From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
Sent: Saturday, May 04, 2002 1:01 AM
To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith
(Keith)
Subject: Dialog-ID and Replaces reconciliation


Eric, Rohan:

The SIP Replaces header and the P-Original-Dialog-ID header seem to 
have some common parts. For instance, both define mechanisms to 
transport the to-tag and the from-tag in the header value.

I was wondering if it would be possible to re-use as much as possible
from the other.

For instance, Replaces defines "to-tag" and "from-tag", whereas
P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think
it would be much better if P-Original-Dialog-ID defines "to-tag" and
"from-tag". The "original-dialog" meaning is implicitely carried 
in the header name and syntax.

This would allow easier definition of the SIP dictionary used in 
compression, because we don't need different entries in the 
dictionary. It would also allow to reuse as much as possible the
software code in an implementation.

On the other hand, Replaces seems to lack a "call-id=" string. 
P-Original-Dialog-ID has it, and it is certainly needed. Is there
a way to synchronize these two??

I hope you can take my comments onboard.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002


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



From daemon@optimus.ietf.org  Tue May  7 01:41:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19535
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 01:41:35 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA29604
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 01:41:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28567;
	Tue, 7 May 2002 01:18:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28536
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 01:18:04 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19342
	for <sip@ietf.org>; Tue, 7 May 2002 01:17:54 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g475Hw0E004519;
	Tue, 7 May 2002 07:17:58 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g475Hv9q027981;
	Tue, 7 May 2002 08:17:57 +0300 (EET DST)
Message-ID: <3CD76380.B3D8A024@ericsson.com>
Date: Tue, 07 May 2002 08:17:52 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
CC: sip@ietf.org, Rohan Mahy <rohan@cisco.com>,
        "Drage, Keith (Keith)" <drage@lucent.com>
References: <47AF9FA8BB0DD611A75C00A0C9AA883C026055B5@il0015exch004u.ih.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Dialog-ID and Replaces reconciliation
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Eric, Rohan, Keith:

No rush. I think the important thing is to synchronize both headers.

My suggestion for both is to use the following syntax.

     P-Original-Dialog-ID = "P-Original-Dialog-ID" HCOLON dialog-value 
     dialog-value         = call-id COMMA to-tag COMMA from-tag 
                            [COMMA extension-param]
     call-id              = "call-id" EQUAL callid
     to-tag               = "to-tag" EQUAL token
     from-tag             = "from-tag" EQUAL token
     extension-param      = token [EQUAL (token | quoted-string)]

Example:

P-Original-Dialog-ID: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983

And for Replaces:
      Replaces         = "Replaces" HCOLON replaces-values
                          *(COMMA replaces-values)

      replaces-values  = call-id *( SEMI replaces-param )
      call-id          = "call-id" EQUAL callid
      replaces-param   = to-tag | from-tag | extension-param
      to-tag           = "to-tag" EQUAL ( token | "*" )
      from-tag         = "from-tag" EQUAL token
      extension-param  = token [ EQUAL ( token | quoted-string ) ]

Example:

Replaces: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983

Is this acceptable???

/Miguel

"Henrikson, Eric H (Eric)" wrote:
> 
> Miguel, Rohan,
> 
> I took a look at the Replaces header and I see some similarities.  However,
> I don't think I'm going to have time today to rework the syntax and submit
> all my 3GPP contributions.  So I think this will have to wait until later
> this week.
> 
> Eric
> 
> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> Sent: Saturday, May 04, 2002 1:01 AM
> To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith
> (Keith)
> Subject: Dialog-ID and Replaces reconciliation
> 
> Eric, Rohan:
> 
> The SIP Replaces header and the P-Original-Dialog-ID header seem to
> have some common parts. For instance, both define mechanisms to
> transport the to-tag and the from-tag in the header value.
> 
> I was wondering if it would be possible to re-use as much as possible
> from the other.
> 
> For instance, Replaces defines "to-tag" and "from-tag", whereas
> P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think
> it would be much better if P-Original-Dialog-ID defines "to-tag" and
> "from-tag". The "original-dialog" meaning is implicitely carried
> in the header name and syntax.
> 
> This would allow easier definition of the SIP dictionary used in
> compression, because we don't need different entries in the
> dictionary. It would also allow to reuse as much as possible the
> software code in an implementation.
> 
> On the other hand, Replaces seems to lack a "call-id=" string.
> P-Original-Dialog-ID has it, and it is certainly needed. Is there
> a way to synchronize these two??
> 
> I hope you can take my comments onboard.
> 
> /Miguel
> 
> --
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
> mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Tue May  7 03:40:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29500
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 03:40:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA04928
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 03:40:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03808;
	Tue, 7 May 2002 03:15:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03774
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 03:15:44 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29248
	for <sip@ietf.org>; Tue, 7 May 2002 03:15:34 -0400 (EDT)
From: bernhard.honeisen@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g477G0n04082
	for <sip@ietf.org>; Tue, 7 May 2002 10:16:01 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5ab6d60687ac158f23077@esvir03nok.nokia.com>;
 Tue, 7 May 2002 10:15:36 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 7 May 2002 10:15:40 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F596.FDF5CA50"
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Tue, 7 May 2002 10:15:39 +0300
Message-ID: <E392EEA75EC5F54AB75229B693B1B6A70133F00E@esebe018.NOE.Nokia.com>
Thread-Topic: [Sip] Re: WGLC for draft-willis-sip-path-05
Thread-Index: AcH1MmGUbLz/n2oeTcGM3jLVEOUv5gAZBdqA
To: <sriramp@nortelnetworks.com>, <Miguel.A.Garcia@ericsson.com>,
        <dean.willis@SOFTARMOR.COM>
Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>
X-OriginalArrivalTime: 07 May 2002 07:15:40.0362 (UTC) FILETIME=[FE4FB2A0:01C1F596]
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

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

Hi Sriram !
=20
Will be fixed in the next version.
Thanks for pointing this out.
=20
cheers,
 Bernie

-----Original Message-----
From: ext Sriram Parameswar [mailto:sriramp@nortelnetworks.com]
Sent: 06 May, 2002 21:52
To: 'Miguel A. Garcia'; Dean Willis
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard =
(NET/Helsinki)
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05



Dean, Bernie,=20

One more recommendation:=20

** Since the draft adds an option tag "path". I would highly recommend =
that put "Supported:path,...." in all REGISTER's shown in the draft.

Thanks,=20

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


-----Original Message-----=20
From: Miguel A. Garcia [ mailto:Miguel.A.Garcia@ericsson.com]=20
Sent: Monday, May 06, 2002 1:36 AM=20
To: Dean Willis=20
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;=20
bernhard.honeisen@nokia.com=20
Subject: [Sip] Re: WGLC for draft-willis-sip-path-05=20


Dean, Bernie:=20

Some comments to the Path header, mostly NITS.=20

1) Regarding the tag option "Path" for the Supported header, as far as=20
   I have seen before, most of the other option tags are defined in=20
   lowercase. I would suggest to follow the same approach for =
consistency,=20
   that is, define "path".=20

2) The syntax defined at the end of section 3 does not allow the Path=20
   header to be part of the request, only to the response. I suspect=20
   this is an error. Suggestion:=20

         Header field          where   proxy ACK BYE CAN INV OPT REG PRA =

         _______________________________________________________________ =

         Path                    R       ar   -   -   -   -   -   o   -=20
         Path                   2xx       -   -   -   -   -   -   o   -=20

3) The last sentence in section 4.1 reads: "The UA should include the=20
   option tag 'Path' in any Supported headers". I suspect this inclusion =

   affects all the instances of Supported, including those in an INVITE. =

   Can you confirm this?=20

4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be=20
   replaced by reference [2] (bis-09).=20

5) In section 4.7, the Via in the examples do not begin with "z9hG4bK"=20
   as required by bis-09.=20

Thanks a lot,=20

       Miguel=20


Dean Willis wrote:=20
>=20
> I'd like to request Working Group Last Call for draft-willis-sip-path. =

> This will need to close by about 11May.=20
>=20
> Version -05 draft has been submitted to internet-drafts and shoudl be=20
> available.=20
>=20
> in the meantime use:=20
>=20
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt=20
>=20
> or=20
>=20
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html=20
>=20
> --=20
> Dean=20

--=20
Miguel-Angel Garcia                     Oy LM Ericsson AB=20
                                        Jorvas, Finland=20
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553=20
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002=20

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


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [Sip] Re: WGLC for draft-willis-sip-path-05</TITLE>

<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D705561107-07052002><FONT face=3DArial color=3D#008000 =
size=3D2>Hi=20
Sriram !</FONT></SPAN></DIV>
<DIV><SPAN class=3D705561107-07052002><FONT face=3DArial color=3D#008000 =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705561107-07052002><FONT face=3DArial color=3D#008000 =
size=3D2>Will=20
be fixed in the next version.</FONT></SPAN></DIV>
<DIV><SPAN class=3D705561107-07052002></SPAN><SPAN =
class=3D705561107-07052002><FONT=20
face=3DArial color=3D#008000 size=3D2>Thanks for pointing this=20
out.</FONT></SPAN></DIV>
<DIV><SPAN class=3D705561107-07052002><FONT face=3DArial color=3D#008000 =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D705561107-07052002><FONT face=3DArial color=3D#008000 =

size=3D2>cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=3D705561107-07052002><FONT face=3DArial color=3D#008000 =

size=3D2>&nbsp;Bernie</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #008000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> ext Sriram =
Parameswar=20
  [mailto:sriramp@nortelnetworks.com]<BR><B>Sent:</B> 06 May, 2002=20
  21:52<BR><B>To:</B> 'Miguel A. Garcia'; Dean Willis<BR><B>Cc:</B>=20
  3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard=20
  (NET/Helsinki)<BR><B>Subject:</B> RE: [Sip] Re: WGLC for=20
  draft-willis-sip-path-05<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Dean, Bernie,</FONT> </P>
  <P><FONT size=3D2>One more recommendation:</FONT> </P>
  <P><FONT size=3D2>** Since the draft adds an option tag "path". I =
would highly=20
  recommend that put "Supported:path,...." in all REGISTER's shown in =
the=20
  draft.</FONT></P>
  <P><FONT size=3D2>Thanks,</FONT> </P>
  <P><FONT size=3D2>Sriram</FONT> <BR><FONT=20
  size=3D2>__________________________________________</FONT> <BR><FONT=20
  size=3D2>Sriram=20
  =
Parameswar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
  Phone: 972-685-8540</FONT> <BR><FONT size=3D2>Interactive Multimedia =
Server=20
  (IMS) Fax: 972-684-3986</FONT> <BR><FONT size=3D2>Nortel Networks, =
Richardson=20
  USA&nbsp; Email: sriramp@nortelnetworks.com</FONT> </P><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Miguel A. Garcia [<A=20
  =
href=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@erics=
son.com</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Monday, May 06, 2002 1:36 AM</FONT> <BR><FONT =

  size=3D2>To: Dean Willis</FONT> <BR><FONT size=3D2>Cc:=20
  3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;</FONT> <BR><FONT=20
  size=3D2>bernhard.honeisen@nokia.com</FONT> <BR><FONT =
size=3D2>Subject: [Sip] Re:=20
  WGLC for draft-willis-sip-path-05</FONT> </P><BR>
  <P><FONT size=3D2>Dean, Bernie:</FONT> </P>
  <P><FONT size=3D2>Some comments to the Path header, mostly =
NITS.</FONT> </P>
  <P><FONT size=3D2>1) Regarding the tag option "Path" for the Supported =
header,=20
  as far as </FONT><BR><FONT size=3D2>&nbsp;&nbsp; I have seen before, =
most of the=20
  other option tags are defined in </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  lowercase. I would suggest to follow the same approach for =
consistency,</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp; that is, define "path".</FONT> </P>
  <P><FONT size=3D2>2) The syntax defined at the end of section 3 does =
not allow=20
  the Path </FONT><BR><FONT size=3D2>&nbsp;&nbsp; header to be part of =
the=20
  request, only to the response. I suspect </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  this is an error. Suggestion:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Header=20
  field&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
where&nbsp;&nbsp;=20
  proxy ACK BYE CAN INV OPT REG PRA</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  _______________________________________________________________</FONT> =

  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
Path&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ar&nbsp;&nbsp; -&nbsp;&nbsp;=20
  -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; o&nbsp;&nbsp; =
-</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
Path&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  2xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp;=20
  -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; o&nbsp;&nbsp; =
-</FONT>=20
  </P>
  <P><FONT size=3D2>3) The last sentence in section 4.1 reads: "The UA =
should=20
  include the</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; option tag 'Path' =
in any=20
  Supported headers". I suspect this inclusion</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; affects all the instances of Supported, =
including those in=20
  an INVITE.</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; Can you confirm =
this?</FONT>=20
  </P>
  <P><FONT size=3D2>4) Reference 1 (RFC 2543) and to "the binding" =
(section 4.3)=20
  should be</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; replaced by reference =
[2]=20
  (bis-09).</FONT> </P>
  <P><FONT size=3D2>5) In section 4.7, the Via in the examples do not =
begin with=20
  "z9hG4bK"</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; as required by =
bis-09.</FONT>=20
  </P>
  <P><FONT size=3D2>Thanks a lot,</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Miguel</FONT> =
</P><BR>
  <P><FONT size=3D2>Dean Willis wrote:</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; I'd like to request Working Group Last =
Call for=20
  draft-willis-sip-path.</FONT> <BR><FONT size=3D2>&gt; This will need =
to close by=20
  about 11May.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Version=20
  -05 draft has been submitted to internet-drafts and shoudl be</FONT> =
<BR><FONT=20
  size=3D2>&gt; available.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; in the meantime use:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; <A target=3D_blank=20
  =
href=3D"http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.tx=
t">http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt</A>=
</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; or</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; <A target=3D_blank=20
  =
href=3D"http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.ht=
ml">http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html</=
A></FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; --</FONT> =
<BR><FONT=20
  size=3D2>&gt; Dean</FONT> </P>
  <P><FONT size=3D2>-- </FONT><BR><FONT size=3D2>Miguel-Angel=20
  =
Garcia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Oy LM Ericsson AB</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
  Jorvas, Finland</FONT> <BR><FONT size=3D2><A=20
  =
href=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@erics=
son.com</A>&nbsp;&nbsp;&nbsp;&nbsp;=20
  Phone:&nbsp; +358 9 299 3553</FONT> <BR><FONT size=3D2><A=20
  =
href=3D"mailto:Miguel.A.Garcia@piuha.net">mailto:Miguel.A.Garcia@piuha.ne=
t</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Mobile: +358 40 5140002</FONT> </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Sip mailing list&nbsp; <A target=3D_blank=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/sip">https://www1.ietf.org=
/mailman/listinfo/sip</A></FONT>=20
  <BR><FONT size=3D2>This list is for NEW development of the core SIP=20
  Protocol</FONT> <BR><FONT size=3D2>Use =
sip-implementors@cs.columbia.edu for=20
  questions on current sip</FONT> <BR><FONT size=3D2>Use =
sipping@ietf.org for new=20
  developments on the application of sip</FONT> =
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1F596.FDF5CA50--

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



From daemon@optimus.ietf.org  Tue May  7 03:40:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29517
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 03:40:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA04942
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 03:40:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03882;
	Tue, 7 May 2002 03:17:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03851
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 03:17:42 -0400 (EDT)
Received: from nghmail ([63.104.239.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29266
	for <sip@ietf.org>; Tue, 7 May 2002 03:17:32 -0400 (EDT)
Received: (qmail 32368 invoked from network); 7 May 2002 08:16:58 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.93)
  by nghmail with SMTP; 7 May 2002 08:16:58 -0000
Message-ID: <001a01c1f531$f5863320$5601a8c0@knowsys.net>
From: "vishal" <vishal@knowsys.net>
To: <ietf@ietf.org>
Cc: <sip@ietf.org>
Date: Tue, 7 May 2002 00:40:35 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000F_01C1F55F.CD36BF60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [Sip] comments for UPDATE method
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C1F55F.CD36BF60
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi ,

 I have following comments

regards, vishal

comments:

1. Timer handling section should be included. UPDATE response timer must =
be less than initial INVITE timer.Every time new UPDATE command is =
issued in early dialog,wait timer (of initial INVITE response) must be =
adjusted .=20

2. UPDATE response is sent without prompting remote user .It requires =
UPDATE can be issued only from trusted party .It means user issuing =
UPDATE command MUST send authentication info along with UPDATE command .

3. In section 5.3 "Processing the UPDATE Response"

It is written that

"If a UA receives a non-2xx final response to a UPDATE, the session =
parameters MUST remain unchanged, as if no UPDATE had been issued.Note =
that, as stated in Section 12.2.1 of RFC BBBB [1], if the non-2xx final =
response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request =
Timeout), or no response at all is received for the UPDATE (that is, a =
timeout is returned by the UPDATE client transaction), the UAC will =
terminate the dialog."

In case no response received for UPDATE then UAC SHOULD not terminate =
the dialog.Response to UPDATE may be delayed,lost,currupted due to many =
reasons

for ex. message was routed through many proxies OR UAS,proxy took more =
time in processing of authentication,locating user etc .Response to =
UPDATE received after timer expiry SHOULD be rejected and session =
parametre SHOULD remain unchanged .Dialog SHOULD not be terminated .

UPDATE failure MUST not affect ongoing dialog.

queries:

1. Can UPDATE be over TCP when initial INVITE was over UDP ,so that more =
UPDATEs can be sent over same TCP connection?

2. Can UPDATE be issued only for SDP modification purposes or it can be =
issued to modify contact info,call-id,allow fields etc.?

3. Can UPDATE be generated by other SIP entities(redirect server,proxies =
etc) if they want to enforce particular session parametres based =
dialog.?

SUGGESTION=20

UPDATE should be used only for early dialogs .For confirmed dialogs =
,re-INVITE MUST be used to avoid inconsistancy




Vishal ,
Knowledge Systems Pvt Ltd  ,INDIA
470, East End Main Road =20
9th Block Jayanagar ,
Bangalore 560 069 =20
Telephone: +91-80-6545252

------=_NextPart_000_000F_01C1F55F.CD36BF60
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 content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<P><FONT face=3DArial>Hi ,</FONT></P>
<P><FONT face=3DArial>&nbsp;I have following comments</FONT></P>
<P><FONT face=3DArial>regards, vishal</FONT></P>
<P><FONT face=3DArial><U>comments:</U></FONT></P>
<P><FONT face=3DArial>1. Timer handling section should be included. =
UPDATE=20
response timer must </FONT><FONT face=3DArial>be less than initial =
INVITE=20
timer.Every time new UPDATE command is </FONT><FONT face=3DArial>issued =
in early=20
dialog,</FONT><FONT face=3DArial>wait timer (of initial INVITE response) =
must be=20
adjusted . </FONT></P>
<P><FONT face=3DArial>2. UPDATE response is sent without prompting =
remote user .It=20
requires </FONT><FONT face=3DArial>UPDATE can be issued only from =
trusted party=20
.It means user issuing UPDATE command </FONT><FONT face=3DArial>MUST =
send=20
authentication info along with UPDATE command .</FONT></P>
<P><FONT face=3DArial>3. In section 5.3 "Processing the UPDATE=20
Response"</FONT></P>
<P><FONT face=3DArial>It is written that</FONT></P>
<P><FONT face=3DArial>"If a UA receives a non-2xx final response to a =
UPDATE, the=20
session </FONT><FONT face=3DArial>parameters MUST remain unchanged, as =
if no=20
UPDATE had been issued.</FONT><FONT face=3DArial>Note that, as stated in =
Section=20
12.2.1 of RFC BBBB [1], if the non-</FONT><FONT face=3DArial>2xx final =
response is=20
a 481 (Call/Transaction Does Not Exist), or a </FONT><FONT =
face=3DArial>408=20
(Request Timeout), or no response at all is received for the =
</FONT><FONT=20
face=3DArial>UPDATE (that is, a timeout is returned by the UPDATE client =

</FONT><FONT face=3DArial>transaction), the UAC will terminate the=20
dialog."</FONT></P>
<P><FONT face=3DArial>In case no response received for UPDATE then UAC =
SHOULD not=20
terminate the dialog</FONT><FONT face=3DArial>.Response to UPDATE may be =

delayed,lost,currupted due to many reasons</FONT></P>
<P><FONT face=3DArial>for ex. message was routed through </FONT><FONT=20
face=3DArial>many proxies OR UAS,proxy took more time in processing of=20
authentication,locating user etc .</FONT><FONT face=3DArial>Response to =
UPDATE=20
received after timer expiry SHOULD be rejected and </FONT><FONT=20
face=3DArial>session parametre SHOULD remain unchanged =
.Dialog&nbsp;SHOULD not be=20
terminated .</FONT></P>
<P><FONT face=3DArial>UPDATE failure MUST not affect ongoing =
dialog.</FONT></P>
<P><FONT face=3DArial><U>queries</U>:</FONT></P>
<P><FONT face=3DArial>1. Can UPDATE be over TCP when initial INVITE was =
over UDP=20
,so that more UPDATEs </FONT><FONT face=3DArial>can be sent over same =
TCP=20
connection?</FONT></P>
<P><FONT face=3DArial>2. Can UPDATE be issued only for SDP modification =
purposes=20
or it can be issued </FONT><FONT face=3DArial>to modify contact =
info,call-id,allow=20
fields etc.?</FONT></P>
<P><FONT face=3DArial>3. Can UPDATE be generated by other SIP =
entities(redirect=20
server,proxies etc) if they </FONT><FONT face=3DArial>want to enforce =
particular=20
session parametres based dialog.?</FONT></P>
<P><FONT face=3DArial><U>SUGGESTION </U></FONT></P>
<P><FONT face=3DArial>UPDATE should be used only for early dialogs .For =
confirmed=20
dialogs ,</FONT><FONT face=3DArial>re-INVITE MUST be used to avoid=20
inconsistancy</FONT></P></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Vishal ,<BR>Knowledge Systems Pvt =
Ltd&nbsp;=20
,INDIA<BR>470, East End Main Road&nbsp; <BR>9th Block Jayanagar =
,<BR>Bangalore=20
560 069&nbsp; <BR>Telephone: +91-80-6545252</FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C1F55F.CD36BF60--


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



From daemon@optimus.ietf.org  Tue May  7 08:01:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03830
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 08:01:29 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA19423
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 08:01:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16910;
	Tue, 7 May 2002 07:35:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16846
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 07:35:15 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02763;
	Tue, 7 May 2002 07:35:07 -0400 (EDT)
Message-Id: <200205071135.HAA02763@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 07 May 2002 07:35:06 -0400
Subject: [Sip] I-D ACTION:draft-willis-sip-path-05.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIP Extension for Registering Non-Adjacent Contacts
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-path-05.txt
	Pages		: 16
	Date		: 06-May-02
	
The REGISTER function is used in a SIP system primarily to associate
a temporary contact address with an address-of-record.  This contact
is generally in the form of a URI, such as Contact:
<sip:alice@pc33.atlanta.com> and is generally dynamic and associated
with the IP address or hostname of the SIP UA.  The problem is that
network topology may be that there are one or more SIP proxies
between the UA and the registrar, such that any message from the
user's home network to the registered UA must traverse these proxies.
The REGISTER method does not give us a mechanism to discover and
record this sequence of proxies in the registrar for future use.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-willis-sip-path-05.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Tue May  7 08:01:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03864
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 08:01:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA19507
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 08:01:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16897;
	Tue, 7 May 2002 07:35:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA16848
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 07:35:15 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02747;
	Tue, 7 May 2002 07:35:03 -0400 (EDT)
Message-Id: <200205071135.HAA02747@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 07 May 2002 07:35:01 -0400
Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-03.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIP Extension Header for Service Route Discovery in 
                          Private Networks
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-scvrtdisco-03.txt
	Pages		: 15
	Date		: 06-May-02
	
This document proposes a private SIP extension header used in
conjunction with responses to REGISTER messages to provide a
mechanism by which a registrar may inform a registering UA of a
service route that the UA may use to request outbound services from
the registrar's domain.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-willis-sip-scvrtdisco-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-willis-sip-scvrtdisco-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:	<20020506144219.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-willis-sip-scvrtdisco-03.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Tue May  7 11:27:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12317
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 11:27:30 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA04258
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 11:27:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01960;
	Tue, 7 May 2002 10:59:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01931
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 10:59:22 -0400 (EDT)
Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11098
	for <sip@ietf.org>; Tue, 7 May 2002 10:59:15 -0400 (EDT)
From: "Salva Rey Calatayud" <salreyca@teleco.upv.es>
To: sip@ietf.org
Date: Sun, 7 May 2000 17:12:37 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Reply-to: salreyca@teleco.upv.es
Message-ID: <3915A405.16258.6C13F04@localhost>
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12cDE)
X-SMTP-Server: PostCast Server 1.0.0
Content-Transfer-Encoding: 7BIT
Subject: [Sip] forking dialogs
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

Hi,

	can there be any other reason different to parallel forking, that 
could lead a call to consist of several dialogs?

thanks,
Salva


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



From daemon@optimus.ietf.org  Tue May  7 12:10:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14087
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 12:10:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA08685
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 12:10:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06144;
	Tue, 7 May 2002 11:45:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06112
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 11:45:35 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13326
	for <sip@ietf.org>; Tue, 7 May 2002 11:45:23 -0400 (EDT)
Received: from sponge.cisco.com (IDENT:mirapoint@sponge.cisco.com [64.101.128.87])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g47Fixp6008708;
	Tue, 7 May 2002 08:45:00 -0700 (PDT)
Received: from ARUNVENKW2Kl (arunvenk-w2kl-1.cisco.com [64.101.164.76])
	by sponge.cisco.com (Mirapoint)
	with SMTP id AAU75574;
	Tue, 7 May 2002 10:44:58 -0500 (CDT)
From: "Arunachalam Venkatraman" <arunvenk@cisco.com>
To: <salreyca@teleco.upv.es>, <sip@ietf.org>
Subject: RE: [Sip] forking dialogs
Date: Tue, 7 May 2002 10:44:58 -0500
Message-ID: <GFEJJOMGHDNDPFCCCIGNMECNCMAA.arunvenk@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
In-Reply-To: <3915A405.16258.6C13F04@localhost>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Redirection(3xx response to INVITE) results in multiple dialogs which are
not simultaneous.
Call Transfer using Refer can result in a new dialog if the transferred call
leg uses the same call id for the new call(dialog). In this case, both
dialogs are simultaenous.

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Salva
Rey Calatayud
Sent: Sunday, May 07, 2000 10:13 AM
To: sip@ietf.org
Subject: [Sip] forking dialogs


Hi,

	can there be any other reason different to parallel forking, that
could lead a call to consist of several dialogs?

thanks,
Salva


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May  7 13:38:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17586
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 13:38:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA14361
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 13:38:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12421;
	Tue, 7 May 2002 13:07:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12389
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 13:07:54 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16258
	for <sip@ietf.org>; Tue, 7 May 2002 13:07:47 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A9E4489400FC; Tue, 07 May 2002 13:07:48 -0400
Message-ID: <00b601c1f5e9$0e6268c0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Dean Willis" <dean.willis@softarmor.com>
Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>,
        <bernhard.honeisen@nokia.com>
References: <002301c1f478$b385d570$133fed0c@C1893415A> <3CD62433.C1714CB@ericsson.com>
Date: Tue, 7 May 2002 13:03:05 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for draft-willis-sip-path-05: Require:path needed?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Dean,

Maybe I am missing something, but how do we make sure the registrar can
support the Path header? The UA probably does not care, but the intervening
proxies probably need to know that the "Path" cannot honored by the
registrar. I suppose the proxy could insert Require:path if it saw the
Supported:path in the request.

I think the spec should say that UAs that want to allow a Path to be
inserted MUST add Supported:path to the REGISTER request and that a proxy
MUST NOT add a Path header if Supported:path is not present. The proxy
inserting a Path header SHOULD add Require:path to guarantee that the
registrar supports Path. If the request is rejected with 420, the UA SHOULD
resubmit without Supported:path.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.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 daemon@optimus.ietf.org  Tue May  7 13:50:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18187
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 13:50:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA15124
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 13:50:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13260;
	Tue, 7 May 2002 13:19:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13236
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 13:19:56 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16796
	for <sip@ietf.org>; Tue, 7 May 2002 13:19:46 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id ACB6D05200D8; Tue, 07 May 2002 13:19:50 -0400
Message-ID: <00b901c1f5ea$bb9d86e0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>,
        "Dean Willis" <dean.willis@softarmor.com>
Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>,
        <bernhard.honeisen@nokia.com>
References: <002301c1f478$b385d570$133fed0c@C1893415A> <3CD62433.C1714CB@ericsson.com>
Subject: Re: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Tue, 7 May 2002 13:15:06 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

see below

----- Original Message -----
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>

> Dean, Bernie:
>
> Some comments to the Path header, mostly NITS.
>
> 1) Regarding the tag option "Path" for the Supported header, as far as
>    I have seen before, most of the other option tags are defined in
>    lowercase. I would suggest to follow the same approach for consistency,
>    that is, define "path".

I also think it should be "path".

>
> 2) The syntax defined at the end of section 3 does not allow the Path
>    header to be part of the request, only to the response. I suspect
>    this is an error. Suggestion:
>
>          Header field          where   proxy ACK BYE CAN INV OPT REG PRA
>          _______________________________________________________________
>          Path                    R       ar   -   -   -   -   -   o   -
>          Path                   2xx       -   -   -   -   -   -   o   -

A prior e-mail said that a UA was not allowed include a Path header. Is
there a particular reason we want to prohibit the UA from contributing to
the path? I can't think of a particular example, but a UA could know that a
specific element needs to be on the inbound path, and that element may not
be in the register path (just like a proxy adding "a Path element
referencing another node" as described in section 4.2).

>
> 3) The last sentence in section 4.1 reads: "The UA should include the
>    option tag 'Path' in any Supported headers". I suspect this inclusion
>    affects all the instances of Supported, including those in an INVITE.
>    Can you confirm this?

The Supported:path is only needed in the REGISTER request. Why would the UA
need to include it in INVITEs it sends? And how would a Calling UA know to
include it? I don't think the Calling party needs to consent to the Called
party's registered Path.

cheers,
(-:bob


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



From daemon@optimus.ietf.org  Tue May  7 13:56:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18452
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 13:56:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA15450
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 13:56:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14540;
	Tue, 7 May 2002 13:40:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14509
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 13:40:50 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17650
	for <sip@ietf.org>; Tue, 7 May 2002 13:40:42 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47HdNd18545;
	Tue, 7 May 2002 12:39:23 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <jh@lohi.eng.song.fi>
Cc: <sip@ietf.org>, "'3GPP_TSG_CN_WG1'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        <bernhard.honeisen@nokia.com>, "'Rohan Mahy'" <rohan@cisco.com>,
        <brian.rosen@marconi.com>, <jo@ipdialog.com>
Subject: RE: [Sip] WGLC for draft-willis-sip-path-05
Date: Tue, 7 May 2002 12:39:20 -0500
Message-ID: <014401c1f5ee$1f8f9690$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <15574.14707.901024.844778@harjus.eng.song.fi>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of jh@lohi.eng.song.fi
> Sent: Monday, May 06, 2002 3:06 AM
> To: Dean Willis
> Cc: sip@ietf.org; 3GPP_TSG_CN_WG1; 
> bernhard.honeisen@nokia.com; Rohan Mahy; 
> brian.rosen@marconi.com; jo@ipdialog.com
> Subject: [Sip] WGLC for draft-willis-sip-path-05
> 
> 
> below are my comments:
> 
> - i thought that it was agreed to use name rrr instead of 
> path for this
>   header.  the reason is that this header is both semantically and
>   syntactically very close to record-route.  also, name path is not at
>   all descriptive, what path?

I polled the list on April 1, and received about a dozen responses
indicating a preference for Path. Nobody responded in favor of RRR.

 
> - this paragraph should be moved, since somebody's 
> suggestions regarding
>   things that are outside the scope of the i-d should not be part of
>   the normative text:
> 
>   It has been suggested that the UA MAY choose to store the 
> contents of
>   the Path header for future use as a preloaded Route for use when the
>   UA wishes to send a SIP message that, for reasons of acquiring
>   services in the home network, need to transit the service proxies in
>   the home network.  Such usage is explicitly outside the 
> scope of this
>   document.
> 

This seems reasonable, and unless there are objections I intend to
delete in next revision.

--
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 daemon@optimus.ietf.org  Tue May  7 16:06:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22850
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 16:06:54 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA16835
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:07:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14720;
	Tue, 7 May 2002 15:41:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14435
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 15:41:33 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20121
	for <sip@ietf.org>; Tue, 7 May 2002 14:47:16 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47Ikld21627;
	Tue, 7 May 2002 13:46:47 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>
Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>,
        <bernhard.honeisen@nokia.com>
Date: Tue, 7 May 2002 13:46:37 -0500
Message-ID: <016b01c1f5f7$895c7670$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <00b601c1f5e9$0e6268c0$2300000a@acmepacket.com>
Content-Transfer-Encoding: 7bit
Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Bob said:
> Maybe I am missing something, but how do we make sure the 
> registrar can support the Path header? The UA probably does 
> not care, but the intervening proxies probably need to know 
> that the "Path" cannot honored by the registrar. I suppose 
> the proxy could insert Require:path if it saw the 
> Supported:path in the request.
> 
> I think the spec should say that UAs that want to allow a 
> Path to be inserted MUST add Supported:path to the REGISTER 
> request and that a proxy MUST NOT add a Path header if 
> Supported:path is not present. The proxy inserting a Path 
> header SHOULD add Require:path to guarantee that the 
> registrar supports Path. If the request is rejected with 420, 
> the UA SHOULD resubmit without Supported:path.

I think this works. It does have the side effect that a UA that doesn't
know about Path can't be served by a proxy network that requires it even
though there are no functional changes needed in the UA.

--
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 daemon@optimus.ietf.org  Tue May  7 16:07:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22898
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 16:07:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA16850
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:07:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14788;
	Tue, 7 May 2002 15:41:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14492
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 15:41:36 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18782
	for <sip@ietf.org>; Tue, 7 May 2002 14:07:55 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47I7Od19915;
	Tue, 7 May 2002 13:07:24 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>,
        <bernhard.honeisen@nokia.com>
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Tue, 7 May 2002 13:07:21 -0500
Message-ID: <014801c1f5f2$08f85df0$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <00b901c1f5ea$bb9d86e0$2300000a@acmepacket.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Bob asked:
> A prior e-mail said that a UA was not allowed include a Path 
> header. Is there a particular reason we want to prohibit the 
> UA from contributing to the path? I can't think of a 
> particular example, but a UA could know that a specific 
> element needs to be on the inbound path, and that element may 
> not be in the register path (just like a proxy adding "a Path 
> element referencing another node" as described in section 4.2).

That's a reasonable question. It's not consistent with the original
intent, but on first analysis, I can't think of a real reason that this
COULDN'T be done. Anybody else out there have an opinion?

>
> > 3) The last sentence in section 4.1 reads: "The UA should 
> include the
> >    option tag 'Path' in any Supported headers". I suspect 
> this inclusion
> >    affects all the instances of Supported, including those 
> in an INVITE.
> >    Can you confirm this?
> 
> The Supported:path is only needed in the REGISTER request. 
> Why would the UA need to include it in INVITEs it sends? And 
> how would a Calling UA know to include it? I don't think the 
> Calling party needs to consent to the Called party's registered Path.

The Supported mechanism is not method specific. This is part of why
option tags may not be such a good idea. The UA is supposed to include
an option tag for EVERY extension it supports in EVERY case in which it
sends a Supported header.

>From bis:

20.37 Supported 
4429 The Supported header field enumerates all the extensions supported
by the UAC or UAS. 
4430 The Supported header field contains a list of option tags,
described in Section 19.2, that are understood 
4431 by the UAC or UAS. A UA compliant to this specification MUST only
include option tags corresponding to 
4432 standards-track RFCs. If empty, it means that no extensions are
supported. 

It doesn't really matter whether the calling UA understands Path or not
-- it is applied by the called party's proxy.

Conversely, I'm not sure that it matters all that much whether the
registering UA understands Path. If it doesn't, it can't sanity-check
the response in 200Ok, but that doesn't keep the path mechanism from
working.

One possibility (and I believe this is the justification for Supported
in this case) is that the UA knows whether its registrar supports Path,
and that intermediate proxies can use the presence of a Supported header
for path as hint to decide whether they may safely include Path headers.
One could for example use this mechanism to allow a proxy to reject a
registration when the proxy knows that it requires Path functionality,
and the UA doesn't indicate support for the header. This seems like a
slight stretching of the Supported functionality, but should work.

What we don't have is a way to have perfect forward knowledge in the
proxy which inserts Path that the registrar processing the registration
understands Path. Perhaps there's a way to get this using Require?

For example, the UA could do a Require: path if it thinks that there's
any chance that intermediate proxies will need 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 daemon@optimus.ietf.org  Tue May  7 16:07:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22937
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 16:07:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA16924
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:07:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14795;
	Tue, 7 May 2002 15:41:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14519
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 15:41:37 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18780
	for <sip@ietf.org>; Tue, 7 May 2002 14:07:52 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47I7Pd19920;
	Tue, 7 May 2002 13:07:25 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Sriram Parameswar'" <sriramp@nortelnetworks.com>,
        "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: <sip@ietf.org>, <bernhard.honeisen@nokia.com>
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Tue, 7 May 2002 13:07:21 -0500
Message-ID: <014901c1f5f2$09b76830$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_014A_01C1F5C8.20E16030"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <EF1056F8EB4ED511B8FB0002A56079D401E5B05F@zrc2c014.us.nortel.com>
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_014A_01C1F5C8.20E16030
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

excellent suggestion.
 
--
dean

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Sriram
Parameswar
Sent: Monday, May 06, 2002 1:52 PM
To: 'Miguel A. Garcia'; Dean Willis
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;
bernhard.honeisen@nokia.com
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05



Dean, Bernie, 

One more recommendation: 

** Since the draft adds an option tag "path". I would highly recommend
that put "Supported:path,...." in all REGISTER's shown in the draft.

Thanks, 

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


-----Original Message----- 
From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] 
Sent: Monday, May 06, 2002 1:36 AM 
To: Dean Willis 
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; 
bernhard.honeisen@nokia.com 
Subject: [Sip] Re: WGLC for draft-willis-sip-path-05 


Dean, Bernie: 

Some comments to the Path header, mostly NITS. 

1) Regarding the tag option "Path" for the Supported header, as far as 
   I have seen before, most of the other option tags are defined in 
   lowercase. I would suggest to follow the same approach for
consistency, 
   that is, define "path". 

2) The syntax defined at the end of section 3 does not allow the Path 
   header to be part of the request, only to the response. I suspect 
   this is an error. Suggestion: 

         Header field          where   proxy ACK BYE CAN INV OPT REG PRA

         _______________________________________________________________

         Path                    R       ar   -   -   -   -   -   o   - 
         Path                   2xx       -   -   -   -   -   -   o   - 

3) The last sentence in section 4.1 reads: "The UA should include the 
   option tag 'Path' in any Supported headers". I suspect this inclusion

   affects all the instances of Supported, including those in an INVITE.

   Can you confirm this? 

4) Reference 1 (RFC 2543) and to "the binding" (section 4.3) should be 
   replaced by reference [2] (bis-09). 

5) In section 4.7, the Via in the examples do not begin with "z9hG4bK" 
   as required by bis-09. 

Thanks a lot, 

       Miguel 


Dean Willis wrote: 
> 
> I'd like to request Working Group Last Call for draft-willis-sip-path.

> This will need to close by about 11May. 
> 
> Version -05 draft has been submitted to internet-drafts and shoudl be 
> available. 
> 
> in the meantime use: 
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.txt 
> 
> or 
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.html 
> 
> -- 
> Dean 

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB 
                                        Jorvas, Finland 
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553 
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002 

_______________________________________________ 
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
This list is for NEW development of the core SIP 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_014A_01C1F5C8.20E16030
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=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D106034917-07052002><FONT face=3DArial color=3D#0000ff =

size=3D2>excellent suggestion.</FONT></SPAN></DIV>
<DIV><SPAN class=3D106034917-07052002><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D106034917-07052002><FONT face=3DArial color=3D#0000ff =

size=3D2>--</FONT></SPAN></DIV>
<DIV><SPAN class=3D106034917-07052002><FONT face=3DArial color=3D#0000ff =

size=3D2>dean</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  sip-admin@ietf.org [mailto:sip-admin@ietf.org] <B>On Behalf Of =
</B>Sriram=20
  Parameswar<BR><B>Sent:</B> Monday, May 06, 2002 1:52 PM<BR><B>To:</B> =
'Miguel=20
  A. Garcia'; Dean Willis<BR><B>Cc:</B> 3GPP_TSG_CN_WG1@LIST.ETSI.FR;=20
  sip@ietf.org; bernhard.honeisen@nokia.com<BR><B>Subject:</B> RE: [Sip] =
Re:=20
  WGLC for draft-willis-sip-path-05<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Dean, Bernie,</FONT> </P>
  <P><FONT size=3D2>One more recommendation:</FONT> </P>
  <P><FONT size=3D2>** Since the draft adds an option tag "path". I =
would highly=20
  recommend that put "Supported:path,...." in all REGISTER's shown in =
the=20
  draft.</FONT></P>
  <P><FONT size=3D2>Thanks,</FONT> </P>
  <P><FONT size=3D2>Sriram</FONT> <BR><FONT=20
  size=3D2>__________________________________________</FONT> <BR><FONT=20
  size=3D2>Sriram=20
  =
Parameswar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;=20
  Phone: 972-685-8540</FONT> <BR><FONT size=3D2>Interactive Multimedia =
Server=20
  (IMS) Fax: 972-684-3986</FONT> <BR><FONT size=3D2>Nortel Networks, =
Richardson=20
  USA&nbsp; Email: sriramp@nortelnetworks.com</FONT> </P><BR>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Miguel A. Garcia [<A=20
  =
href=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@erics=
son.com</A>]</FONT>=20
  <BR><FONT size=3D2>Sent: Monday, May 06, 2002 1:36 AM</FONT> <BR><FONT =

  size=3D2>To: Dean Willis</FONT> <BR><FONT size=3D2>Cc:=20
  3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;</FONT> <BR><FONT=20
  size=3D2>bernhard.honeisen@nokia.com</FONT> <BR><FONT =
size=3D2>Subject: [Sip] Re:=20
  WGLC for draft-willis-sip-path-05</FONT> </P><BR>
  <P><FONT size=3D2>Dean, Bernie:</FONT> </P>
  <P><FONT size=3D2>Some comments to the Path header, mostly =
NITS.</FONT> </P>
  <P><FONT size=3D2>1) Regarding the tag option "Path" for the Supported =
header,=20
  as far as </FONT><BR><FONT size=3D2>&nbsp;&nbsp; I have seen before, =
most of the=20
  other option tags are defined in </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  lowercase. I would suggest to follow the same approach for =
consistency,</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp; that is, define "path".</FONT> </P>
  <P><FONT size=3D2>2) The syntax defined at the end of section 3 does =
not allow=20
  the Path </FONT><BR><FONT size=3D2>&nbsp;&nbsp; header to be part of =
the=20
  request, only to the response. I suspect </FONT><BR><FONT =
size=3D2>&nbsp;&nbsp;=20
  this is an error. Suggestion:</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Header=20
  field&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
where&nbsp;&nbsp;=20
  proxy ACK BYE CAN INV OPT REG PRA</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  _______________________________________________________________</FONT> =

  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
Path&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ar&nbsp;&nbsp; -&nbsp;&nbsp;=20
  -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; o&nbsp;&nbsp; =
-</FONT>=20
  <BR><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
Path&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  2xx&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp;=20
  -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; o&nbsp;&nbsp; =
-</FONT>=20
  </P>
  <P><FONT size=3D2>3) The last sentence in section 4.1 reads: "The UA =
should=20
  include the</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; option tag 'Path' =
in any=20
  Supported headers". I suspect this inclusion</FONT> <BR><FONT=20
  size=3D2>&nbsp;&nbsp; affects all the instances of Supported, =
including those in=20
  an INVITE.</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; Can you confirm =
this?</FONT>=20
  </P>
  <P><FONT size=3D2>4) Reference 1 (RFC 2543) and to "the binding" =
(section 4.3)=20
  should be</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; replaced by reference =
[2]=20
  (bis-09).</FONT> </P>
  <P><FONT size=3D2>5) In section 4.7, the Via in the examples do not =
begin with=20
  "z9hG4bK"</FONT> <BR><FONT size=3D2>&nbsp;&nbsp; as required by =
bis-09.</FONT>=20
  </P>
  <P><FONT size=3D2>Thanks a lot,</FONT> </P>
  <P><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Miguel</FONT> =
</P><BR>
  <P><FONT size=3D2>Dean Willis wrote:</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; I'd like to request Working Group Last =
Call for=20
  draft-willis-sip-path.</FONT> <BR><FONT size=3D2>&gt; This will need =
to close by=20
  about 11May.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Version=20
  -05 draft has been submitted to internet-drafts and shoudl be</FONT> =
<BR><FONT=20
  size=3D2>&gt; available.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; in the meantime use:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; <A=20
  =
href=3D"http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.tx=
t"=20
  =
target=3D_blank>http://www.softarmor.com/sipwg/drafts/draft-willis-sip-pa=
th-05.txt</A></FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; or</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; <A=20
  =
href=3D"http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-05.ht=
ml"=20
  =
target=3D_blank>http://www.softarmor.com/sipwg/drafts/draft-willis-sip-pa=
th-05.html</A></FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; --</FONT> =
<BR><FONT=20
  size=3D2>&gt; Dean</FONT> </P>
  <P><FONT size=3D2>-- </FONT><BR><FONT size=3D2>Miguel-Angel=20
  =
Garcia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Oy LM Ericsson AB</FONT> <BR><FONT=20
  =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
  Jorvas, Finland</FONT> <BR><FONT size=3D2><A=20
  =
href=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@erics=
son.com</A>&nbsp;&nbsp;&nbsp;&nbsp;=20
  Phone:&nbsp; +358 9 299 3553</FONT> <BR><FONT size=3D2><A=20
  =
href=3D"mailto:Miguel.A.Garcia@piuha.net">mailto:Miguel.A.Garcia@piuha.ne=
t</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Mobile: +358 40 5140002</FONT> </P>
  <P><FONT =
size=3D2>_______________________________________________</FONT>=20
  <BR><FONT size=3D2>Sip mailing list&nbsp; <A=20
  href=3D"https://www1.ietf.org/mailman/listinfo/sip"=20
  target=3D_blank>https://www1.ietf.org/mailman/listinfo/sip</A></FONT> =
<BR><FONT=20
  size=3D2>This list is for NEW development of the core SIP =
Protocol</FONT>=20
  <BR><FONT size=3D2>Use sip-implementors@cs.columbia.edu for questions =
on current=20
  sip</FONT> <BR><FONT size=3D2>Use sipping@ietf.org for new =
developments on the=20
  application of sip</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_014A_01C1F5C8.20E16030--


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



From daemon@optimus.ietf.org  Tue May  7 16:12:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23052
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 16:12:13 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA17165
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 16:12:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13338;
	Tue, 7 May 2002 15:30:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12996
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 15:29:53 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19364
	for <sip@ietf.org>; Tue, 7 May 2002 14:29:31 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id AD0FE503010E; Tue, 07 May 2002 14:29:35 -0400
Message-ID: <001301c1f5f4$6f650000$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
        "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>,
        <bernhard.honeisen@nokia.com>
References: <014801c1f5f2$08f85df0$4a010114@TXDWILLIS2>
Subject: Re: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Tue, 7 May 2002 14:24:33 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Dean Willis" <dean.willis@softarmor.com>
<snip>
> > > 3) The last sentence in section 4.1 reads: "The UA should
> > include the
> > >    option tag 'Path' in any Supported headers". I suspect
> > this inclusion
> > >    affects all the instances of Supported, including those
> > in an INVITE.
> > >    Can you confirm this?
> >
> > The Supported:path is only needed in the REGISTER request.
> > Why would the UA need to include it in INVITEs it sends? And
> > how would a Calling UA know to include it? I don't think the
> > Calling party needs to consent to the Called party's registered Path.
>
> The Supported mechanism is not method specific. This is part of why
> option tags may not be such a good idea. The UA is supposed to include
> an option tag for EVERY extension it supports in EVERY case in which it
> sends a Supported header.
>
OK. But surely the UA is allowed to exclude features (option tags) it does
not want used for a given request.

<snip>
> It doesn't really matter whether the calling UA understands Path or not
> -- it is applied by the called party's proxy.
>
> Conversely, I'm not sure that it matters all that much whether the
> registering UA understands Path. If it doesn't, it can't sanity-check
> the response in 200Ok, but that doesn't keep the path mechanism from
> working.

I almost see the UA's inclusion of "Supported:path" as 'permission' for the
intervening elements to insert Path headers (you know all that stuff about
the knowledge and consent of the user). That's why I think proxies should be
forbidden from adding Path headers if Supported:path is not present.

>
> One possibility (and I believe this is the justification for Supported
> in this case) is that the UA knows whether its registrar supports Path,
> and that intermediate proxies can use the presence of a Supported header
> for path as hint to decide whether they may safely include Path headers.
> One could for example use this mechanism to allow a proxy to reject a
> registration when the proxy knows that it requires Path functionality,
> and the UA doesn't indicate support for the header. This seems like a
> slight stretching of the Supported functionality, but should work.
>
> What we don't have is a way to have perfect forward knowledge in the
> proxy which inserts Path that the registrar processing the registration
> understands Path. Perhaps there's a way to get this using Require?
>
> For example, the UA could do a Require: path if it thinks that there's
> any chance that intermediate proxies will need it.

By having the proxy that is inserting a Path header add the Require:path,
you eliminate the rejection of the request by a registrar that does not
support 'path' when no Path headers have been added.




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



From daemon@optimus.ietf.org  Tue May  7 17:36:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24836
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 17:36:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA22856
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 17:36:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14444;
	Tue, 7 May 2002 13:40:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14413
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 13:40:02 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17642
	for <sip@ietf.org>; Tue, 7 May 2002 13:39:55 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g47HdPd18548;
	Tue, 7 May 2002 12:39:26 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>,
        <bernhard.honeisen@nokia.com>
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Tue, 7 May 2002 12:39:20 -0500
Message-ID: <014501c1f5ee$20502770$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CD62433.C1714CB@ericsson.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Miguel wrote:
> 1) Regarding the tag option "Path" for the Supported header, 
> as far as 
>    I have seen before, most of the other option tags are defined in 
>    lowercase. I would suggest to follow the same approach for 
> consistency,
>    that is, define "path".

Works for me.
 
> 2) The syntax defined at the end of section 3 does not allow the Path 
>    header to be part of the request, only to the response. I suspect 
>    this is an error. Suggestion:
> 
>          Header field          where   proxy ACK BYE CAN INV 
> OPT REG PRA
>          
> _______________________________________________________________
>          Path                    R       ar   -   -   -   -   
> -   o   -
>          Path                   2xx       -   -   -   -   -   
> -   o   -

I'm busy arguing with Jonathan about the meaning of stuff in table 2. As
I read it, the formulation I've given says that the UA (see bis line
4036) MUST NOT insert a Path header in a request, but that a proxy MAY
add a Path header, or add to an existing Path header inserted by another
proxy. The registrar, which is a UA, MAY (support for Path is optional)
insert a Path header in the 2xx response to the request, and proxies
MUST NOT modify or delete that header from the response.


However, Jonathan has now decided that the text around 4036 is an error,
and there's no way to actually describe the logic above in table 2/3.
This furthers the arguments that tables 2/3 need to be either deleted or
replaced. Jonathan suggests we follow the example of Record-Route and
Proxy-Authenticate, which according to Table 2/3 is allowed in a message
from a UA even though it makes no sense at all.

In short, anybody who's relying on Table 2/3 to provide a truth table
for their implementation is likely to be sorely disappointed.


> 3) The last sentence in section 4.1 reads: "The UA should include the
>    option tag 'Path' in any Supported headers". I suspect 
> this inclusion
>    affects all the instances of Supported, including those in 
> an INVITE.
>    Can you confirm this?

Yes, "path" should be included in any Supported headers sent by the UA.
At least that's my understanding of the Supported mechanism. It seems to
make sense only in REGISTER, but (and I just verified with Jonathan) the
Supported mechanism is not method specific, so it goes in any Supported
header.

--
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 daemon@optimus.ietf.org  Tue May  7 20:09:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27578
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 20:09:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA29991
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 20:09:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28588;
	Tue, 7 May 2002 19:48:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28559
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 19:48:27 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27218
	for <sip@ietf.org>; Tue, 7 May 2002 19:48:19 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g47NlpE26147;
	Tue, 7 May 2002 18:47:51 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXX3HBZ>; Tue, 7 May 2002 18:48:04 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B065@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: "'Dean Willis'" <dwillis@dynamicsoft.com>, sip@ietf.org,
        rsparks@dynamicsoft.com
Subject: RE: [Sip] WGLC SIP MIME Types Registration Draft
Date: Tue, 7 May 2002 18:47:57 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F621.9D6F3830"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1F621.9D6F3830
Content-Type: text/plain;
	charset="iso-8859-1"

Hi:

Quoting section 1 "If the message/sipfrag part contains a body, it must also
contain a Content-Length header and the null-line separating headers from
the body." 

I think it would be a good idea to include the Content-Type and possibly
other Content related headers (Content-Encoding, Content-Language etc.) - as
a SHOULD strength. I am not sure what good it would do, to get a body
without the requisite information to extract its true meaning.

Thanks,

Sriram

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


-----Original Message-----
From: Dean Willis [mailto:dwillis@dynamicsoft.com]
Sent: Thursday, May 02, 2002 5:32 PM
To: sip@ietf.org
Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison Mankin';
jo@ipdialog.com; rsparks@dynamicsoft.com
Subject: [Sip] WGLC SIP MME Types Registration Draft


I'd like to request WGLC of the SIP MIME type registration draft.

The current version can be found at:

http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt

Or

http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt



We'd like to close WGLC by about May 21.

Please copy comments to the list and to Robert Sparks, who will
coordinate further efforts.

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Sip] WGLC SIP MIME Types Registration Draft</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>Quoting section 1 &quot;If the message/sipfrag part =
contains a body, it must also contain a Content-Length header and the =
null-line separating headers from the body.&quot; </FONT></P>

<P><FONT SIZE=3D2>I think it would be a good idea to include the =
Content-Type and possibly other Content related headers =
(Content-Encoding, Content-Language etc.) - as a SHOULD strength. I am =
not sure what good it would do, to get a body without the requisite =
information to extract its true meaning.</FONT></P>

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

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

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Dean Willis [<A =
HREF=3D"mailto:dwillis@dynamicsoft.com">mailto:dwillis@dynamicsoft.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 02, 2002 5:32 PM</FONT>
<BR><FONT SIZE=3D2>To: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison =
Mankin';</FONT>
<BR><FONT SIZE=3D2>jo@ipdialog.com; rsparks@dynamicsoft.com</FONT>
<BR><FONT SIZE=3D2>Subject: [Sip] WGLC SIP MME Types Registration =
Draft</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I'd like to request WGLC of the SIP MIME type =
registration draft.</FONT>
</P>

<P><FONT SIZE=3D2>The current version can be found at:</FONT>
</P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes=
-03.txt" =
TARGET=3D"_blank">http://www.softarmor.com/sipwg/drafts/draft-sparks-sip=
-mimetypes-03.txt</A></FONT>
</P>

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

<P><FONT SIZE=3D2><A =
HREF=3D"http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetype=
s-03.txt" =
TARGET=3D"_blank">http://search.ietf.org/internet-drafts/draft-sparks-si=
p-mimetypes-03.txt</A></FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>We'd like to close WGLC by about May 21.</FONT>
</P>

<P><FONT SIZE=3D2>Please copy comments to the list and to Robert =
Sparks, who will</FONT>
<BR><FONT SIZE=3D2>coordinate further efforts.</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Dean</FONT>
</P>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>This list is for NEW development of the core SIP =
Protocol</FONT>
<BR><FONT SIZE=3D2>Use sip-implementors@cs.columbia.edu for questions =
on current sip</FONT>
<BR><FONT SIZE=3D2>Use sipping@ietf.org for new developments on the =
application of sip</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F621.9D6F3830--

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



From daemon@optimus.ietf.org  Tue May  7 21:11:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28310
	for <sip-archive@odin.ietf.org>; Tue, 7 May 2002 21:11:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA03125
	for sip-archive@odin.ietf.org; Tue, 7 May 2002 21:11:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01630;
	Tue, 7 May 2002 20:45:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01602
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 20:45:28 -0400 (EDT)
Received: from crash.dfw.dynamicsoft.com ([63.110.3.64])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27970
	for <sip@ietf.org>; Tue, 7 May 2002 20:45:19 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g480mmV23610;
	Tue, 7 May 2002 19:48:49 -0500
Subject: RE: [Sip] WGLC SIP MIME Types Registration Draft
From: Robert Sparks <rsparks@dynamicsoft.com>
To: Sriram Parameswar <sriramp@nortelnetworks.com>
Cc: "'Dean Willis'" <dwillis@dynamicsoft.com>, sip@ietf.org
In-Reply-To: 
	<EF1056F8EB4ED511B8FB0002A56079D401E5B065@zrc2c014.us.nortel.com>
References: 
	<EF1056F8EB4ED511B8FB0002A56079D401E5B065@zrc2c014.us.nortel.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 07 May 2002 17:37:28 -0700
Message-Id: <1020818249.1320.53.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Ok.

The right way to say this is to call to 
section 7.4.1 of bis-09/rfc3261 for what is required
if a body is present. I'll make that change.

RjS

On Tue, 2002-05-07 at 16:47, Sriram Parameswar wrote:
> Hi: 
> 
> Quoting section 1 "If the message/sipfrag part contains a body, it must
> also contain a Content-Length header and the null-line separating
> headers from the body." 
> 
> I think it would be a good idea to include the Content-Type and possibly
> other Content related headers (Content-Encoding, Content-Language etc.)
> - as a SHOULD strength. I am not sure what good it would do, to get a
> body without the requisite information to extract its true meaning.
> 
> Thanks, 
> 
> Sriram 
> 
> __________________________________________ 
> Sriram Parameswar              Phone: 972-685-8540 
> Interactive Multimedia Server (IMS) Fax: 972-684-3986 
> Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com 
> 
> 
> -----Original Message----- 
> From: Dean Willis [ mailto:dwillis@dynamicsoft.com
> <mailto:dwillis@dynamicsoft.com> ] 
> Sent: Thursday, May 02, 2002 5:32 PM 
> To: sip@ietf.org 
> Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison Mankin'; 
> jo@ipdialog.com; rsparks@dynamicsoft.com 
> Subject: [Sip] WGLC SIP MME Types Registration Draft 
> 
> 
> I'd like to request WGLC of the SIP MIME type registration draft. 
> 
> The current version can be found at: 
> 
> http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt
> <http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt
> >  
> 
> Or 
> 
> http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt
> <http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.tx
> t>  
> 
> 
> 
> We'd like to close WGLC by about May 21. 
> 
> Please copy comments to the list and to Robert Sparks, who will 
> coordinate further efforts. 
> 
> -- 
> Dean 
> 
> 
> 
> _______________________________________________ 
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> <https://www1.ietf.org/mailman/listinfo/sip>  
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Wed May  8 03:37:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28146
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 03:37:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA10004
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 03:37:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08945;
	Wed, 8 May 2002 03:13:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08914
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 03:13:17 -0400 (EDT)
Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27912
	for <sip@ietf.org>; Wed, 8 May 2002 03:13:10 -0400 (EDT)
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
	by goliath.siemens.de (8.11.6/8.11.6) with ESMTP id g487DHD00862
	for <sip@ietf.org>; Wed, 8 May 2002 09:13:17 +0200 (MEST)
Received: from hvrz00da.hvr.siemens.de (hvrz00da.hvr.siemens.de [129.103.192.197])
	by mail3.siemens.de (8.11.6/8.11.6) with ESMTP id g487DGM25064
	for <sip@ietf.org>; Wed, 8 May 2002 09:13:17 +0200 (MEST)
Received: by hvrz00da.hvr.siemens.de with Internet Mail Service (5.5.2653.19)
	id <KL5S3SM5>; Wed, 8 May 2002 09:13:17 +0200
Message-ID: <F56AAADD3A90D311A0220090275CCDE202104B19@hvrz00da.hvr.siemens.de>
From: BECKMANN MARK <mark.beckmann@sal.siemens.de>
To: sip@ietf.org
Date: Wed, 8 May 2002 09:13:08 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RE: Expert Review of draft-beckmann-sip-event
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

I have just submitted an update of the informational draft on the
registration-state event package (draft-beckmann-sip-reg-event-01). It
should come up on the SIP list, soon. Please use this version for the expert
review.

This update mainly adds a request for registration of the event package in
section 4 "IANA considerations". Additionally it aligns the draft with the
latest version of the CPIM Presence format draft
draft-ietf-impp-cpim-pidf-03.

Mark

Mark Beckmann			Siemens AG

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

mailto: Mark.Beckmann@siemens.com



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Friday, May 03, 2002 12:32 AM
> To: sip@ietf.org
> Cc: 'Allison Mankin'; 'Rohan Mahy'; 'Brian Rosen'; jo@ipdialog.com;
> BECKMANN MARK
> Subject: Expert Review of draft-beckmann-sip-event
> Importance: High
> 
> 
> 
> The SIP Working Group has been requested to provide Expert 
> Review of an
> events package for registration state.
> 
> The current version is available at:
> 
> http://www.softarmor.com/sipwg/drafts/draft-beckmann-sip-reg-e
vent-00.tx
t

Or

http://search.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-00.t
xt


Please copy responses to the list and to Mark Beckmann, who will
coordinate needed edits.

--
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 daemon@optimus.ietf.org  Wed May  8 04:36:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28945
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 04:36:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA12361
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 04:36:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10444;
	Wed, 8 May 2002 03:56:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10413
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 03:56:02 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28368
	for <sip@ietf.org>; Wed, 8 May 2002 03:55:53 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g487tw0E010050;
	Wed, 8 May 2002 09:55:58 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.33])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g487tv9q009451;
	Wed, 8 May 2002 10:55:57 +0300 (EET DST)
Message-ID: <3CD8DA07.37ADA947@ericsson.com>
Date: Wed, 08 May 2002 10:55:51 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
CC: sip@ietf.org, Rohan Mahy <rohan@cisco.com>,
        "Drage, Keith (Keith)" <drage@lucent.com>
References: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EE7@il0015exch004u.ih.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Dialog-ID and Replaces reconciliation
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Eric:

The to-tag will be different only because Replaces will allow
a star "*". But if you consider that a star is a token, then
it is exacltly the same definition.

Rohan, any views on the proposed change to Replaces?

/Miguel

"Henrikson, Eric H (Eric)" wrote:
> 
> Miguel,
> 
> What you proposed looks fine.  I'm not certain about one thing though.  If
> the intent is to have the same definition for call-id, from-tag and to-tag,
> then there is still a difference with the proposed definitions of to-tag.
> Does this mean that only the Replaces header version of to-tag would apply
> if both headers are eventually adopted as standard headers?
> To put it another way, is it allowed to have multiple definitions of to-tag
> if both headers are adopted?
> 
> Eric
> 
> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> Sent: Monday, May 06, 2002 10:18 PM
> To: Henrikson, Eric H (Eric)
> Cc: sip@ietf.org; Rohan Mahy; Drage, Keith (Keith)
> Subject: Re: Dialog-ID and Replaces reconciliation
> 
> Eric, Rohan, Keith:
> 
> No rush. I think the important thing is to synchronize both headers.
> 
> My suggestion for both is to use the following syntax.
> 
>      P-Original-Dialog-ID = "P-Original-Dialog-ID" HCOLON dialog-value
>      dialog-value         = call-id COMMA to-tag COMMA from-tag
>                             [COMMA extension-param]
>      call-id              = "call-id" EQUAL callid
>      to-tag               = "to-tag" EQUAL token
>      from-tag             = "from-tag" EQUAL token
>      extension-param      = token [EQUAL (token | quoted-string)]
> 
> Example:
> 
> P-Original-Dialog-ID: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983
> 
> And for Replaces:
>       Replaces         = "Replaces" HCOLON replaces-values
>                           *(COMMA replaces-values)
> 
>       replaces-values  = call-id *( SEMI replaces-param )
>       call-id          = "call-id" EQUAL callid
>       replaces-param   = to-tag | from-tag | extension-param
>       to-tag           = "to-tag" EQUAL ( token | "*" )
>       from-tag         = "from-tag" EQUAL token
>       extension-param  = token [ EQUAL ( token | quoted-string ) ]
> 
> Example:
> 
> Replaces: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983
> 
> Is this acceptable???
> 
> /Miguel
> 
> "Henrikson, Eric H (Eric)" wrote:
> >
> > Miguel, Rohan,
> >
> > I took a look at the Replaces header and I see some similarities.
> However,
> > I don't think I'm going to have time today to rework the syntax and submit
> > all my 3GPP contributions.  So I think this will have to wait until later
> > this week.
> >
> > Eric
> >
> > -----Original Message-----
> > From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> > Sent: Saturday, May 04, 2002 1:01 AM
> > To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith
> > (Keith)
> > Subject: Dialog-ID and Replaces reconciliation
> >
> > Eric, Rohan:
> >
> > The SIP Replaces header and the P-Original-Dialog-ID header seem to
> > have some common parts. For instance, both define mechanisms to
> > transport the to-tag and the from-tag in the header value.
> >
> > I was wondering if it would be possible to re-use as much as possible
> > from the other.
> >
> > For instance, Replaces defines "to-tag" and "from-tag", whereas
> > P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think
> > it would be much better if P-Original-Dialog-ID defines "to-tag" and
> > "from-tag". The "original-dialog" meaning is implicitely carried
> > in the header name and syntax.
> >
> > This would allow easier definition of the SIP dictionary used in
> > compression, because we don't need different entries in the
> > dictionary. It would also allow to reuse as much as possible the
> > software code in an implementation.
> >
> > On the other hand, Replaces seems to lack a "call-id=" string.
> > P-Original-Dialog-ID has it, and it is certainly needed. Is there
> > a way to synchronize these two??
> >
> > I hope you can take my comments onboard.
> >
> > /Miguel
> >
> > --
> > Miguel-Angel Garcia                     Oy LM Ericsson AB
> >                                         Jorvas, Finland
> > mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
> > mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002
> 
> --
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
> mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Wed May  8 07:08:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00491
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 07:08:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA19201
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:08:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17613;
	Wed, 8 May 2002 06:33:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17586
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 06:33:43 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00042
	for <sip@ietf.org>; Wed, 8 May 2002 06:33:35 -0400 (EDT)
From: bernhard.honeisen@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g48AXpk29120
	for <sip@ietf.org>; Wed, 8 May 2002 13:33:51 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5abcb18d70ac158f24077@esvir04nok.ntc.nokia.com>;
 Wed, 8 May 2002 13:33:29 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 8 May 2002 13:33:29 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 8 May 2002 13:33:28 +0300
Message-ID: <E392EEA75EC5F54AB75229B693B1B6A70A5294@esebe018.NOE.Nokia.com>
Thread-Topic: WGLC for draft-willis-sip-path-05: Require:path needed?
Thread-Index: AcH1944mM8TlXyXOSsKsfep6ee8gkAAc1vhA
To: <dean.willis@softarmor.com>, <bpenfield@acmepacket.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 08 May 2002 10:33:29.0164 (UTC) FILETIME=[CB14E8C0:01C1F67B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id GAA17587
Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 07 May, 2002 21:47
> To: 'Bob Penfield'
> Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard
> (NET/Helsinki)
> Subject: RE: WGLC for draft-willis-sip-path-05: Require:path needed?
> 
> 
> Bob said:
> > Maybe I am missing something, but how do we make sure the 
> > registrar can support the Path header? The UA probably does 
> > not care, but the intervening proxies probably need to know 
> > that the "Path" cannot honored by the registrar. I suppose 
> > the proxy could insert Require:path if it saw the 
> > Supported:path in the request.
> > 
> > I think the spec should say that UAs that want to allow a 
> > Path to be inserted MUST add Supported:path to the REGISTER 
> > request and that a proxy MUST NOT add a Path header if 
> > Supported:path is not present. The proxy inserting a Path 
> > header SHOULD add Require:path to guarantee that the 
> > registrar supports Path. If the request is rejected with 420, 
> > the UA SHOULD resubmit without Supported:path.
> 
> I think this works. It does have the side effect that a UA 
> that doesn't
> know about Path can't be served by a proxy network that 
> requires it even
> though there are no functional changes needed in the UA.

Do we really want, that the proxies can just insert Paths without
the consent of the user? This is related to the first item
in the Security considerations section.
As the Supported header field can be integrity protected,
the registrar has means, to see, whether the UA really
knows, what is going on with Path.

Besides this, an implementation of the Path to the UA
seams fairly easy.


My proposal is similar as Bob's:

The registrar ignores any Path header if the Supported:path
is not present in that REGISTER request.

A proxy, which inserts a Path header and really wants to stay
on the route for incoming calls, inserts also a Require:path
(if not yet present).

The registrar decides then based on these two headers, what to do:

- The Require:path has the normal meaning:
  -> send 420 response, if registrar does not understood path

- If Supported:path is present in the REGISTER request
  --> use path as described in the I/D.

- If Supported:path is _not_ present in the REGISTER request
  --> _ignore_ any Path,
      regardless of any possible Require:path present


The only problem I see lasting is, that proxies could prevent
a user from registering by just inserting a Require:path.
This looks like a more general problem as this can be
done with any option tag.

Solution:

-> after a 420 the UA tries to send the request without
Supported:path.

-> Proxies MUST NOT insert a Require:path, if no Supported:path
was present in the request.


Comments?

cheers,
 Bernie


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



From daemon@optimus.ietf.org  Wed May  8 07:44:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01707
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 07:44:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA21322
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:44:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20008;
	Wed, 8 May 2002 07:29:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19887
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 07:29:13 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01138;
	Wed, 8 May 2002 07:29:00 -0400 (EDT)
Message-Id: <200205081129.HAA01138@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 08 May 2002 07:28:59 -0400
Subject: [Sip] I-D ACTION:draft-henrikson-sip-charging-information-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private SIP Extension for Mobile Charging Information
	Author(s)	: E. Henrikson
	Filename	: draft-henrikson-sip-charging-information-01.txt
	Pages		: 7
	Date		: 07-May-02
	
This document proposes a private SIP extension header P-Charging-
Function-Addresses used to pass the addresses of entities that 
provide a charging function. There is a need in the Third 
Generation Partnership Project (3GPP) for entities that process 
charging information. For a particular dialog or standalone 
transaction, a proxy (or UA within the network, e.g. a gateway) may 
need to pass information to one or more charging entities. The 
affected UAs and proxies associated with the dialog or standalone 
transaction need to know the identities or addresses of the 
appropriate charging entities. This document also proposes a 
private SIP extension header P-Charging-Vector to pass correlation 
information for charging purposes. The network entities in the 3GPP 
architecture share correlation information to ensure that charging 
activities are coordinated.  The need applies for any SIP method 
used to initiate a dialog, standalone messages and some response 
messages.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-information-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-henrikson-sip-charging-information-01.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-henrikson-sip-charging-information-01.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:	<20020507133254.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-henrikson-sip-charging-information-01.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May  8 07:45:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01740
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 07:45:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA21360
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:45:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19858;
	Wed, 8 May 2002 07:29:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19814
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 07:28:57 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01082;
	Wed, 8 May 2002 07:28:47 -0400 (EDT)
Message-Id: <200205081128.HAA01082@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org, simple@mailman.dynamicsoft.com
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 08 May 2002 07:28:46 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-message-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: Session Initiation Protocol Extension for Instant 
                          Messaging
	Author(s)	: B. Campbell, J. Rosenberg
	Filename	: draft-ietf-sip-message-04.txt
	Pages		: 20
	Date		: 07-May-02
	
Instant Messageing (IM) refers to the transfer of messages between
users in near real-time.  These messages are usually, but not
required to be, short.  IMs are often used in a conversational mode,
that is, the transfer of messages back and forth is fast enough for
participants to maintain an interactive conversation.
The MESSAGE method is an extension to the Session Initation Protocol
(SIP) that allows the transfer of Instant Messages.  MESSAGE requests
carry the content in the form of MIME body parts.  MESSAGE requests
do not themselves initiate a SIP dialog; under normal usage each
Instant Message stands alone, much like pager messages.  MESSAGE
requests may be sent in the context of a dialog initiated by some
other SIP request.
Since the MESSAGE request is an extension to SIP it inherits all the
request routing and security features of that protocol.

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

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

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

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


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

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

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May  8 07:47:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01811
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 07:47:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA21416
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 07:47:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA20029;
	Wed, 8 May 2002 07:29:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19889
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 07:29:14 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01162;
	Wed, 8 May 2002 07:29:04 -0400 (EDT)
Message-Id: <200205081129.HAA01162@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 08 May 2002 07:29:04 -0400
Subject: [Sip] I-D ACTION:draft-henrikson-sip-original-dialog-id-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private SIP Extension for Original Dialog Identifier
	Author(s)	: E. Henrikson
	Filename	: draft-henrikson-sip-original-dialog-id-01.txt
	Pages		: 8
	Date		: 07-May-02
	
This document proposes a private SIP extension header used in 
conjunction with INVITE requests to provide a mechanism by which a 
stateful proxy may associate an INVITE request processed earlier 
with the INVITE request that is being currently processed. The 
association is needed by the Serving Call Session Control Function 
(S-CSCF) from the Third Generation Partnership Project (3GPP) 
architecture to ensure proper routing of an INVITE request with 
3GPP Application Servers (AS). A S-CSCF may route an INVITE request 
to multiple AS, as indicated by a subscriber profile, and each AS 
may be a B2BUA. The S-CSCF needs to keep track of each AS contacted 
and know that an incoming INVITE request is related to a previous 
outgoing INVITE request such that each AS may receive the INVITE 
request before it is sent on towards the intended destination. When 
a B2BUA AS is  involved, there is currently not a way to associate 
the incoming INVITE request with the previously sent INVITE request 
at the S-CSCF. The P-Original-Dialog-ID header provides a way to 
accomplish this association. The same mechanism may be applied to 
any SIP method that is used to initiate a dialog.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-henrikson-sip-original-dialog-id-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-henrikson-sip-original-dialog-id-01.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-henrikson-sip-original-dialog-id-01.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:	<20020507133305.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-henrikson-sip-original-dialog-id-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-henrikson-sip-original-dialog-id-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May  8 09:32:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05541
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 09:32:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA27521
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:33:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25778;
	Wed, 8 May 2002 09:02:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11059
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 12:55:18 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15535
	for <sip@ietf.org>; Tue, 7 May 2002 12:55:10 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g47Gskw07442
	for <sip@ietf.org>; Tue, 7 May 2002 12:54:46 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21)
	id <KG75VWT5>; Tue, 7 May 2002 11:54:46 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EBB@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Cc: jo@ipdialog.com, brian.rosen@marconi.com, Rohan@cicso.com,
        "'Allison Mankin'" <mankin@isi.edu>,
        "Drage, Keith (Keith)"
	 <drage@lucent.com>
Date: Tue, 7 May 2002 11:54:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C1F5E7.DD98BE70"
Subject: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_000_01C1F5E7.DD98BE70
Content-Type: text/plain

Attached is revision 01 of the original-dialog-id draft.

Please return comments by May 10, 2002.


Thank you.
Eric Henrikson

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Wednesday, May 01, 2002 6:38 AM
To: sip@ietf.org
Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison
Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric)
Subject: Expert Review: draft-henrikson-sip-original-dialog-id-00.txt



The SIP working group has been asked to provide expert review of
draft-henrikson-sip-original-dialog-id. This documents a P-header used
in 3GPP to associate dialogs across a 3GPP application server acting as
a back-to-back user agent.

We'd like to complete expert review by May 10, 2002.

Please copy your comments to the list and to Keith Drage and Eric
Henrikson, who will coordinate responses and edit the draft
apporpriately.

Thanks,

--
Dean Willis


------_=_NextPart_000_01C1F5E7.DD98BE70
Content-Type: text/plain;
	name="draft-henrikson-sip-original-dialog-id-01.txt"
Content-Disposition: attachment;
	filename="draft-henrikson-sip-original-dialog-id-01.txt"
Content-Transfer-Encoding: quoted-printable



 Internet Draft                                            E. Henrikson =

 Document: draft-henrikson-sip-original-dialog-id-01             Lucent =

 Expires: November 2002                                    Technologies =

 Category: Informational                                                =

                                                               May 2002 =

 =20
            Private SIP Extension for Original Dialog Identifier=20
                 draft-henrikson-sip-original-dialog-id-01=20
     =20
 Status of this Memo =20
    =20
    This document is an Internet-Draft and is in full conformance with=20
    all provisions of Section 10 of RFC2026. =20
        =20
    Internet-Drafts are working documents of the Internet Engineering=20
    Task Force (IETF), its areas, and its working groups.  Note that=20
    other groups may also distribute working documents as Internet-
    Drafts. =20
        =20
    Internet-Drafts are draft documents valid for a maximum of six=20
    months and may be updated, replaced, or obsoleted by other=20
    documents at any time. It is inappropriate to use Internet-Drafts=20
    as reference material or to cite them other than as "work in=20
    progress." =20
        =20
    The list of current Internet-Drafts can be accessed at =20
         http://www.ietf.org/ietf/1id-abstracts.txt =20
    The list of Internet-Draft Shadow Directories can be accessed at =20
         http://www.ietf.org/shadow.html. =20
        =20
 Abstract =20
    =20
    This document proposes a private SIP extension header used in=20
    conjunction with INVITE requests to provide a mechanism by which a=20
    stateful proxy may associate an INVITE request processed earlier=20
    with the INVITE request that is being currently processed. The=20
    association is needed by the Serving Call Session Control Function=20
    (S-CSCF) from the Third Generation Partnership Project (3GPP)=20
    architecture to ensure proper routing of an INVITE request with=20
    3GPP Application Servers (AS). A S-CSCF may route an INVITE request =

    to multiple AS, as indicated by a subscriber profile, and each AS=20
    may be a B2BUA. The S-CSCF needs to keep track of each AS contacted =

    and know that an incoming INVITE request is related to a previous=20
    outgoing INVITE request such that each AS may receive the INVITE=20
    request before it is sent on towards the intended destination. When =

    a B2BUA AS is  involved, there is currently not a way to associate=20
    the incoming INVITE request with the previously sent INVITE request =

    at the S-CSCF. The P-Original-Dialog-ID header provides a way to=20
    accomplish this association. The same mechanism may be applied to=20
    any SIP method that is used to initiate a dialog.=20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 1]=20
=0C    Private SIP Extension for Original Dialog Identifier  May 2002=20
 =20
 =20
    =20
 Table of Contents=20
    =20
    1. Background....................................................2=20
    2. Discussion of Mechanism.......................................3=20
    3. Applicability Statement.......................................3=20
    4. Syntax........................................................3=20
    5. Usage.........................................................4=20
       5.1 Procedures at the UA......................................4=20
       5.2 Procedures at the Proxy...................................4=20
       5.3 Procedures at the Back to Back UA.........................5=20
       5.4 Examples of Usage.........................................5=20
    6. Security Considerations.......................................6=20
    7. IANA Considerations...........................................7=20
    8. Normative References..........................................7=20
    9. Non-Normative References......................................7=20
    Author's Addresses...............................................7=20
       =20
 1. Background =20
        =20
    3GPP has defined a mechanism for the S-CSCF (a SIP proxy with=20
    additional functionality, which acts as the SIP serving proxy, see=20
    draft-garcia-sipping-3gpp-reqs [3]) to contact multiple Application =

    Servers (AS) when certain SIP events occur, e.g. receiving an=20
    INVITE request. These events are also known as Service Points of=20
    Interest (SPI). The HSS (database entity) provides the S-CSCF with=20
    the list of events and relative priorities of the Application=20
    Servers to contact per event (and other information).  The data=20
    from the HSS is also known as Filter Criteria.  =20
    =20
    When an event occurs that matches an SPI from the Filter Criteria,=20
    the SIP serving proxy needs to contact each AS that is matched=20
    before sending the message on towards the final destination.  Each=20
    AS may alter the message in some way before returning the message=20
    to the SIP serving proxy. Since the message may have been changed=20
    by the AS, including the components of the dialog identifier, the=20
    SIP serving proxy needs some way to determine that the received=20
    message is related to the original message that it sent to the AS.  =

    This will always be needed when an AS is acting as a B2BUA, which=20
    starts a new dialog.=20
    =20
    The solution provided is to include the original dialog id in the=20
    message sent to the AS and to have the AS return the same original=20
    dialog id in the message sent back to the SIP serving proxy.  Then=20
    the SIP serving proxy can make the association between the two=20
    messages and know that the incoming message is related to the=20
    previous outgoing message, which is part of the sequence to contact =

    each AS that matched the Filter Criteria.=20
        =20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 2]=20
=0C    Private SIP Extension for Original Dialog Identifier  May 2002=20
 =20
 =20
 2. Discussion of Mechanism=20
        =20
    The provided mechanism uses a private header "P-Original-Dialog-ID" =

    in an INVITE request forwarded from a proxy. The same mechanism may =

    be applied to other methods that initiate dialogs. The mechanism=20
    only makes sense for stateful proxies that also employ some=20
    application specific logic.=20
    =20
    When a stateful proxy receives an INVITE that does not contain a P-
    Original-Dialog-ID header, then it may choose to insert a P-
    Original-Dialog-ID header into an INVITE request prior to=20
    forwarding the request. If so, it will populate the contents with=20
    the dialog identification fields from the received request: Call-
    ID, From tag and To tag. If there was no To tag in the received=20
    request, then a value of zero will be used for the To parameter in=20
    the P-Original-Dialog-ID header.=20
    =20
    When a stateful proxy receives an INVITE that already contains a P-
    Original-Dialog-ID header, then it may use this information to look =

    for a match with a previously handled dialog. If no match is found, =

    then the message is simply forwarded to the next destination. If a=20
    match is found, then depending on the application specific logic=20
    that may reside with the proxy, the P-Original-Dialog-ID header may =

    be removed from the outbound message.=20
        =20
 3. Applicability Statement=20
        =20
    This mechanism is suitable when forwarding an initial request for a =

    dialog, or a standalone transaction, to an AS that may act as a=20
    B2BUA, and the request is expected to return to the proxy with a=20
    need to correlate the original request and the forwarded request=20
    for the transaction or the dialog.=20
    =20
        =20
 4. Syntax=20
        =20
    All of the mechanisms specified in this document are described in=20
    both prose and an augmented Backus-Naur Form (BNF) defined in RFC=20
    2234 [2]. Further, the BNF definitions from RFC 3261 [1] are=20
    inherited for the P-Original-Dialog-ID header and are not repeated=20
    here. Implementers need to need to be familiar with the notation=20
    and content of RFC 3261 [1] and RFC 2234 [2] to understand this=20
    document.=20
    =20
    The syntax for the P-Original-Dialog-ID header is:=20
    =20
       P-Original-Dialog-ID =3D "P-Original-Dialog-ID" HCOLON=20
                              ( "od-from-tag" EQUAL od-from-tag )=20
                              ( COMMA "od-to-tag" EQUAL od-to-tag )=20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 3]=20
=0C    Private SIP Extension for Original Dialog Identifier  May 2002=20
 =20
 =20
                              ( COMMA "od-call-id" EQUAL od-call-id )=20
    =20
       od-from-tag =3D token=20
    =20
       od-to-tag =3D token=20
    =20
       od-call-id =3D callid=20
    =20
    The allowable usage of headers is described in Table 2 of SIP [1].=20
    The following additions to this table are needed for the P-
    Original-Dialog-ID header.=20
    =20
    Addition of P-Original-Dialog-ID to SIP Table 2:=20
    =20
    Header field       where  proxy ACK BYE CAN INV OPT REG PRA SUB NOT =

    ------------------------------------------------------------------- =

    P-Original-Dialog-ID R     ard   -   -   -   o   o   o   -   o   -=20
       =20
 5. Usage=20
 5.1 Procedures at the UA =20
        =20
    The UAC and UAS (originating and terminating UA) behave as usual.=20
    They are not required to understand the P-Original-Dialog-ID=20
    header, but may retrieve the information if received.=20
        =20
 5.2 Procedures at the Proxy =20
       =20
    The P-Original-Dialog-ID header is treated like any other unknown=20
    header by intermediate proxies.  They simply forward it on towards=20
    the destination.=20
    =20
    If a proxy that supports this extension receives a dialog request=20
    without the P-Original-Dialog-ID header, it may insert a P-
    Original-Dialog-ID header prior to forwarding the message. The od-
    from-tag parameter will be populated with the received From tag=20
    value. The od-to-tag parameter will be populated with the received=20
    To tag value or the value of zero if there was no To tag present.=20
    The od-call-id parameter will be populated with the received Call-
    id value.=20
    =20
    If a proxy that supports this extension receives a dialog request=20
    with the P-Original-Dialog-ID header, it may retrieve the=20
    information from the header to use with application specific logic. =

    The proxy should retain the P-Original-Dialog-ID header in the=20
    outbound message. If the next hop for the message is outside the=20
    network of the proxy, then the proxy may remove the P-Original-
    Dialog-ID header from the message.=20
    =20

 =20
 =20
 Henrikson              Expires - November 2002               [Page 4]=20
=0C    Private SIP Extension for Original Dialog Identifier  May 2002=20
 =20
 =20
    The P-Original-Dialog-ID header carries only tag information, and=20
    therefore does not reveal information that may affect the privacy=20
    of the remote users; however the information contained is of no=20
    relevance to the end UAs and therefore may be removed as defined=20
    above for reasons of protocol efficiency which may be of concern in =

    a radio environment.=20
        =20
 5.3 Procedures at the Back to Back UA =20
 =20
    If a B2BUA that understands the P-Original-Dialog-ID header=20
    receives a dialog request with the P-Original-Dialog-ID header, the =

    B2BUA should copy it from the receiving side UA to the sending side =

    UA.=20
        =20
 5.4 Examples of Usage=20
       =20
    We present example in the context of the scenario presented in the=20
    Background section earlier in this document.  The network diagram=20
    is replicated below:=20
    =20
       Scenario=20
    =20
    =20
    =20
       UA1----P1-----P2-----P1-----P3-----UA2=20
    =20
    =20
    =20
    This example shows the message sequence for an INVITE transaction=20
    originating from UA1 eventually arriving at UA2. P1 is an outbound=20
    proxy for UA1 which routes the request to an Application Server P2. =

    In this case the Application Server acts as a proxy, but it could=20
    equally act as a B2BUA independent of any knowledge of P1. P2=20
    routes the request back to P1 using SIP routeing mechanisms that=20
    are not detailed in this example. P1 correlates the original=20
    request with the returned request. P1 then routes the call via P3=20
    to UA2.=20
    =20
    Message sequence for INVITE using P-Original-Dialog-ID:=20
    =20
        F1 INVITE UA1 -> P1=20
          INVITE sip:joe  SIP/2.0=20
          Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20
          To: Joe <sip:joe>=20
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=3D456248=20
          Call-ID: 843817637684230@998sdasdh09=20
          CSeq: 18 INVITE=20
          Contact: <sip:UA@192.0.2.4>=20
            . . .=20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 5]=20
=0C    Private SIP Extension for Original Dialog Identifier  May 2002=20
 =20
 =20
    =20
        F2 INVITE P1 -> P2=20
          INVITE sip:joe  SIP/2.0=20
          Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20
          Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20
          To: Joe <sip:joe>=20
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=3D456248=20
          Call-ID: 843817637684230@998sdasdh09=20
          CSeq: 18 INVITE=20
          Contact: <sip:UA@192.0.2.4>=20
          P-Original-Dialog-ID: od-from-tag=3D456248,od-to-tag=3D0,=20
                    od-call-id=3D843817637684230@998sdasdh09=20
            . . .=20
    =20
        F3 INVITE P2 -> P1=20
          INVITE sip:joe  SIP/2.0=20
          Via: SIP/2.0/UDP P2:5060;branch=3Dz9hG4bKiokioukju908=20
          Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20
          Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20
          To: Joe <sip:joe>=20
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=3D456248=20
          Call-ID: 843817637684230@998sdasdh09=20
          CSeq: 18 INVITE=20
          Contact: <sip:UA@192.0.2.4>=20
          P-Original-Dialog-ID: od-from-tag=3D456248,od-to-tag=3D0,=20
                    od-call-id=3D843817637684230@998sdasdh09=20
           . . .=20
    =20
    P2 removes the P-Original-Dialog-ID header=20
    =20
        F5 INVITE P1->P3=20
          INVITE sip:joe@UA2=20
          Via: SIP/2.0/USP P1:5060;branch=3Dz9hG4bKHSP10120323=20
          Via: SIP/2.0/UDP P2:5060;branch=3Dz9hG4bKiokioukju908=20
          Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20
          Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20
          To: Joe <sip:joe@UA2>=20
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=3D456248=20
          Call-ID: 843817637684230@998sdasdh09=20
          CSeq: 18 INVITE=20
          Contact: <sip:UA@192.0.2.4>=20
           . . .=20
    =20
       INVITE propagates toward UA2 as usual.=20
    =20
 6. Security Considerations =20
        =20
    It is possible for proxies between the originating UA and the=20
    terminating UA to modify the value of P-Original-Dialog-ID or to=20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 6]=20
=0C    Private SIP Extension for Original Dialog Identifier  May 2002=20
 =20
 =20
    insert a P-Original-Dialog-ID into a request for a dialog, e.g.=20
    INVITE request.  It is also possible for proxies on the INVITE path =

    to execute many different attacks.  It is therefore desirable to=20
    apply transitive mutual authentication using sips: or other=20
    available mechanisms in order to prevent such attacks. =20
    =20
    The information contained is tag information from the original=20
    request, and therefore knowledge of the contents of this header=20
    does not compromise the privacy of the UA or any of the involved=20
    proxies.=20
    =20
 7. IANA Considerations =20
        =20
    This document defines the SIP extension header "P-Original-Dialog-
    ID" which should be included in the registry of SIP headers defined =

    in SIP [1]. As required by the SIP change process draft-tsvarea-
    sipchange [4] the SIP extension header name "Original-Dialog-ID"=20
    should also be registered in association with this extension.=20
        =20
 8. Normative References =20
            =20
    [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,=20
    Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session=20
    Initiation Protocol, RFC 3261", March 2002.=20
    =20
    [2]  D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax=20
    specifications:  ABNF," RFC 2234, Internet Engineering Task Force,=20
    November 1997.=20
    =20
 9. Non-Normative References=20
    =20
    [3]  Garcia, M., et al, "3GPP requirements on SIP,  draft-garcia-
    sipping-3gpp-reqs-03.txt", March 2002.=20
    =20
    [4]  Mankin, A., "SIP Change Process draft-tsvarea-sipchange",=20
    March 2002.=20
       =20
 Author's Addresses =20
        =20
    Eric Henrikson=20
    Lucent Technologies=20
    11601 Willows Rd=20
    Suite 100=20
    Redmond, WA  98052=20
    US=20
    =20
    Phone: +1 425 497 2442=20
    EMail: ehenrikson@lucent.com=20
    URI:   http://www.lucent.com/=20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 7]=20
=0C    Private SIP Extension for Original Dialog Identifier  May 2002=20
 =20
 =20
    =20
    =20
    =20














































 =20
 =20
 Henrikson              Expires - November 2002               [Page 8]=20
=0C
------_=_NextPart_000_01C1F5E7.DD98BE70--


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



From daemon@optimus.ietf.org  Wed May  8 09:36:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05733
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 09:36:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA27751
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:36:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25745;
	Wed, 8 May 2002 09:02:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12480
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 13:08:28 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16264
	for <sip@ietf.org>; Tue, 7 May 2002 13:08:20 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g47H7uQ14229
	for <sip@ietf.org>; Tue, 7 May 2002 13:07:56 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21)
	id <KG75VX64>; Tue, 7 May 2002 12:07:56 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EE7@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Cc: sip@ietf.org, Rohan Mahy <rohan@cisco.com>,
        "Drage, Keith (Keith)"
	 <drage@lucent.com>
Date: Tue, 7 May 2002 12:07:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [Sip] RE: Dialog-ID and Replaces reconciliation
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Miguel,

What you proposed looks fine.  I'm not certain about one thing though.  If
the intent is to have the same definition for call-id, from-tag and to-tag,
then there is still a difference with the proposed definitions of to-tag.
Does this mean that only the Replaces header version of to-tag would apply
if both headers are eventually adopted as standard headers?
To put it another way, is it allowed to have multiple definitions of to-tag
if both headers are adopted?

Eric

-----Original Message-----
From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
Sent: Monday, May 06, 2002 10:18 PM
To: Henrikson, Eric H (Eric)
Cc: sip@ietf.org; Rohan Mahy; Drage, Keith (Keith)
Subject: Re: Dialog-ID and Replaces reconciliation


Eric, Rohan, Keith:

No rush. I think the important thing is to synchronize both headers.

My suggestion for both is to use the following syntax.

     P-Original-Dialog-ID = "P-Original-Dialog-ID" HCOLON dialog-value 
     dialog-value         = call-id COMMA to-tag COMMA from-tag 
                            [COMMA extension-param]
     call-id              = "call-id" EQUAL callid
     to-tag               = "to-tag" EQUAL token
     from-tag             = "from-tag" EQUAL token
     extension-param      = token [EQUAL (token | quoted-string)]

Example:

P-Original-Dialog-ID: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983

And for Replaces:
      Replaces         = "Replaces" HCOLON replaces-values
                          *(COMMA replaces-values)

      replaces-values  = call-id *( SEMI replaces-param )
      call-id          = "call-id" EQUAL callid
      replaces-param   = to-tag | from-tag | extension-param
      to-tag           = "to-tag" EQUAL ( token | "*" )
      from-tag         = "from-tag" EQUAL token
      extension-param  = token [ EQUAL ( token | quoted-string ) ]

Example:

Replaces: call-id=03fdsslkdjfs, to-tag=23049, from-tag=04983

Is this acceptable???

/Miguel

"Henrikson, Eric H (Eric)" wrote:
> 
> Miguel, Rohan,
> 
> I took a look at the Replaces header and I see some similarities.
However,
> I don't think I'm going to have time today to rework the syntax and submit
> all my 3GPP contributions.  So I think this will have to wait until later
> this week.
> 
> Eric
> 
> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> Sent: Saturday, May 04, 2002 1:01 AM
> To: sip@ietf.org; Rohan Mahy; Henrikson, Eric H (Eric); Drage, Keith
> (Keith)
> Subject: Dialog-ID and Replaces reconciliation
> 
> Eric, Rohan:
> 
> The SIP Replaces header and the P-Original-Dialog-ID header seem to
> have some common parts. For instance, both define mechanisms to
> transport the to-tag and the from-tag in the header value.
> 
> I was wondering if it would be possible to re-use as much as possible
> from the other.
> 
> For instance, Replaces defines "to-tag" and "from-tag", whereas
> P-Original-Dialog-ID defines "od-to-tag" and "od-from-tag". I think
> it would be much better if P-Original-Dialog-ID defines "to-tag" and
> "from-tag". The "original-dialog" meaning is implicitely carried
> in the header name and syntax.
> 
> This would allow easier definition of the SIP dictionary used in
> compression, because we don't need different entries in the
> dictionary. It would also allow to reuse as much as possible the
> software code in an implementation.
> 
> On the other hand, Replaces seems to lack a "call-id=" string.
> P-Original-Dialog-ID has it, and it is certainly needed. Is there
> a way to synchronize these two??
> 
> I hope you can take my comments onboard.
> 
> /Miguel
> 
> --
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
> mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002


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



From daemon@optimus.ietf.org  Wed May  8 09:37:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05761
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 09:37:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA27774
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:37:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25824;
	Wed, 8 May 2002 09:02:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11158
	for <sip@optimus.ietf.org>; Tue, 7 May 2002 12:56:03 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15564
	for <sip@ietf.org>; Tue, 7 May 2002 12:55:55 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g47GtVw07794
	for <sip@ietf.org>; Tue, 7 May 2002 12:55:31 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2650.21)
	id <KG75VWWK>; Tue, 7 May 2002 11:55:30 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EBD@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Cc: Rohan@cicso.com, "'Allison Mankin'" <mankin@isi.edu>, jo@ipdialog.com,
        brian.rosen@marconi.com, "Drage, Keith (Keith)" <drage@lucent.com>
Date: Tue, 7 May 2002 11:55:23 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C1F5E7.FA990F70"
Subject: [Sip] Expert Review: draft-henrikson-sip-charging-information-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_000_01C1F5E7.FA990F70
Content-Type: text/plain

Attached is revision 01 of the charging-information draft.

Please return comments by May 10, 2002.


Thank you.
Eric Henrikson

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Wednesday, May 01, 2002 6:38 AM
To: sip@ietf.org
Cc: Rohan@cicso.com; 'Allison Mankin'; jo@ipdialog.com;
brian.rosen@marconi.com; Drage, Keith (Keith); Henrikson, Eric H (Eric)
Subject: Expert Review: draft-henrikson-sip-charging-information-00.txt



The SIP Working Group has been requested to provide expert review of
draft-henrikson-sip-charging-information. This draft documents P-headers
used to interact with the accounting system in 3GPP.

We'd like to complete review by May 10, 2002.


http://www.ietf.org/internet-drafts/draft-henrikson-sip-charging-informa
tion-00.txt


Thanks!

--
Dean Willis


------_=_NextPart_000_01C1F5E7.FA990F70
Content-Type: text/plain;
	name="draft-henrikson-sip-charging-information-01.txt"
Content-Disposition: attachment;
	filename="draft-henrikson-sip-charging-information-01.txt"
Content-Transfer-Encoding: quoted-printable



 Internet Draft                                            E. Henrikson =

 Document: draft-henrikson-sip-charging-information-             Lucent =

 Expires: November 2002                                    Technologies =

 Category: Informational                                                =

                                                               May 2002 =

 =20
           Private SIP Extension for Mobile Charging Information=20
                draft-henrikson-sip-charging-information-01=20
     =20
 Status of this Memo =20
    =20
    This document is an Internet-Draft and is in full conformance with=20
    all provisions of Section 10 of RFC2026. =20
        =20
    Internet-Drafts are working documents of the Internet Engineering=20
    Task Force (IETF), its areas, and its working groups.  Note that=20
    other groups may also distribute working documents as Internet-
    Drafts. =20
        =20
    Internet-Drafts are draft documents valid for a maximum of six=20
    months and may be updated, replaced, or obsoleted by other=20
    documents at any time. It is inappropriate to use Internet-Drafts=20
    as reference material or to cite them other than as "work in=20
    progress." =20
        =20
    The list of current Internet-Drafts can be accessed at =20
         http://www.ietf.org/ietf/1id-abstracts.txt =20
    The list of Internet-Draft Shadow Directories can be accessed at =20
         http://www.ietf.org/shadow.html. =20
        =20
 Abstract =20
    =20
    This document proposes a private SIP extension header P-Charging-
    Function-Addresses used to pass the addresses of entities that=20
    provide a charging function. There is a need in the Third=20
    Generation Partnership Project (3GPP) for entities that process=20
    charging information. For a particular dialog or standalone=20
    transaction, a proxy (or UA within the network, e.g. a gateway) may =

    need to pass information to one or more charging entities. The=20
    affected UAs and proxies associated with the dialog or standalone=20
    transaction need to know the identities or addresses of the=20
    appropriate charging entities. This document also proposes a=20
    private SIP extension header P-Charging-Vector to pass correlation=20
    information for charging purposes. The network entities in the 3GPP =

    architecture share correlation information to ensure that charging=20
    activities are coordinated.  The need applies for any SIP method=20
    used to initiate a dialog, standalone messages and some response=20
    messages. =20
  =20

 =20
 =20
 Henrikson              Expires - November 2002               [Page 1]=20
=0C         Private SIP Extension for Mobile Charging Information=20
                                May 2002=20
 =20
 =20
 Table of Contents=20
    =20
    1. Background....................................................2=20
    2. Discussion of Mechanism.......................................3=20
    3. Applicability Statement.......................................3=20
    4. Syntax........................................................3=20
    5. Usage.........................................................4=20
       5.1 Procedures at the UA......................................4=20
       5.2 Procedures at the Proxy...................................5=20
       5.3 Procedures at the Back to Back UA.........................5=20
       5.4 Examples of Usage.........................................5=20
    6. Security Considerations.......................................6=20
    7. IANA Considerations...........................................6=20
    8. Normative References..........................................7=20
    9. Non-Normative References......................................7=20
    Author's Addresses...............................................7=20
       =20
 1. Background =20
        =20
    3GPP has defined a distributed architecture that results in=20
    multiple network entities becoming involved in providing access and =

    service. Operators need the ability and flexibility to charge for=20
    the access and services as they see fit.  This requires=20
    coordination among the network entities, which includes correlating =

    charging records generated from different entities that are related =

    to the same session.  There is a need to inform each network entity =

    involved about common charging functions to receive the generated=20
    records.=20
    =20
    The solution provided by 3GPP is to define a two types of charging=20
    functions: Charging Collection Function (CCF) and Event Charging=20
    Function (ECF). CCF is used for off-line charging and ECF is used=20
    for on-line charging. There may be a primary and secondary CCF and=20
    ECF, for redundancy purposes. The CCF and ECF addresses may be=20
    passed during the establishment of a dialog or standalone=20
    transaction. The details are specified in the 3GPP documents, see=20
    3GPP TS 32.200 [6].=20
    =20
    Additionally, a charging vector is defined that may be filled in=20
    during the establishment of a dialog or standalone transaction. =20
    The information inside the charging vector may be filled in by=20
    multiple network entities and retrieved by multiple network=20
    entities.  There are three types of correlation information to be=20
    passed: IMS Charging ID (ICID), Inter Operator Identifiers (IOI)=20
    and access network charging information. ICID is a globally unique=20
    value that may be used to correlate charging records. There may an=20
    IOI generated from each side of the dialog to identify the network=20
    associated with each side. The access network charging information=20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 2]=20
=0C         Private SIP Extension for Mobile Charging Information=20
                                May 2002=20
 =20
 =20
    consists of network specific identifiers for the access level (e.g. =

    3GPP radio access network or IEEE 802.11b). =20
        =20
 2. Discussion of Mechanism =20
        =20
    The provided mechanism uses private headers "P-Charging-Function-
    Addresses" and "P-Charging-Vector" in either the initial request or =

    subsequent response for a dialog or standalone transaction.  Only=20
    one instance of each header is allowed in a particular request or=20
    response.=20
    =20
    The mechanisms by which an entity determines which values to=20
    populate in the P-Charging-Function-Addresses and P-Charging-Vector =

    headers are specific to the local implementation and outside the=20
    scope of this document.  =20
        =20
 3. Applicability Statement =20
        =20
    The P-Charging-Function-Addresses and P-Charging-Vector headers are =

    applicable within a single network where coordination of charging=20
    is required according to the architecture specified in 3GPP TS=20
    32.100 [6].  The P-Charging-Vector header is also applicable=20
    between networks.=20
    =20
       =20
 4. Syntax =20
        =20
    All of the mechanisms specified in this document are described in=20
    both prose and an augmented Backus-Naur Form (BNF) defined in RFC=20
    2234 [2]. Further, the BNF definitions from RFC 3261 [1] are=20
    inherited for the P-Charging-Function-Addresses header and are not=20
    repeated here. Implementers need to need to be familiar with the=20
    notation and content of RFC 3261 [2] and RFC 2234 [2] to understand =

    this document.=20
    =20
    The syntax for the P-Charging-Function-Addresses header is:=20
    =20
       P-Charging-Function-Addresses =3D =20
                      "P-Charging-Function-Addresses" HCOLON =20
                        ( "primary-ccf" EQUAL primary-ccf )=20
                        [COMMA "secondary-ccf" EQUAL secondary-ccf]=20
                        [COMMA "primary-ecf" EQUAL primary-ecf]=20
                        [COMMA "secondary-ecf" EQUAL secondary-ecf]=20
    =20
       primary-ccf =3D gen-value=20
    =20
       secondary-ccf =3D gen-value=20
    =20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 3]=20
=0C         Private SIP Extension for Mobile Charging Information 
                                May 2002=20
 =20
 =20
       primary-ecf =3D gen-value=20
    =20
       secondary-ecf =3D gen-value=20
    =20
    The syntax for the P-Charging-Vector header is:=20
    =20
       P-Charging-Vector =3D "P-Charging-Vector" HCOLON=20
                      ( "icid" EQUAL icid )=20
                      [COMMA "ioi-originating" EQUAL ioi-originating]=20
                      [COMMA "ioi-terminating" EQUAL ioi-terminating]=20
                      [COMMA "access-network-charging-info" EQUAL =20
                                  access-network-charging-info]=20
    =20
       icid =3D gen-value=20
    =20
       ioi-originating =3D gen-value=20
    =20
       ioi-terminating =3D gen-value=20
    =20
       access-network-charging-info =3D gen-value=20
    =20
    The allowable usage of headers is described in Table 2 of SIP [1].=20
    The following additions to this table are needed for the P-
    Charging-Function-Addresses and P-Charging-Vector headers.=20
    =20
    Addition of P-Charging-Function-Addresses and P-Charging-Vector to=20
    SIP Table 2:=20
    =20
    Header field       where  proxy ACK BYE CAN INV OPT REG PRA SUB NOT =

    ------------------------------------------------------------------- =

    P-Charging-Function=20
       -Addresses              ard   -   o   -   o   o   o   o   o   o=20
    P-Charging-Vector          ard   -   o   -   o   o   o   o   o   o=20
       =20
    =20
 5. Usage =20
        =20
 5.1 Procedures at the UA =20
        =20
    The UAC and UAS (originating and terminating UA) behave as usual.=20
    They are not required to understand the P-Charging-Function-
    Addresses header, but may retrieve the information if received.=20
    =20
    The UAC and UAS (originating and terminating UA) behave as usual.=20
    They are not required to understand the P-Charging-Vector header,=20
    but may retrieve the information if received.=20
        =20

 =20
 =20
 Henrikson              Expires - November 2002               [Page 4]=20
=0C         Private SIP Extension for Mobile Charging Information=20
                                May 2002=20
 =20
 =20
 5.2 Procedures at the Proxy =20
        =20
    The P-Charging-Function-Addresses and P-Charging-Vector headers are =

    treated like any other unknown header by intermediate proxies. =20
    They simply forward it on towards the destination.=20
    =20
    If a proxy that supports this extension receives a request or=20
    response without the P-Charging-Function-Addresses or P-Charging-
    Vector header, it may insert a P-Charging-Function-Addresses or P-
    Charging-Vector header prior to forwarding the message.=20
    =20
    If a proxy that supports this extension receives a request or=20
    response with the P-Charging-Function-Addresses or P-Charging-
    Vector header, it may retrieve the information from the header to=20
    use with application specific logic, i.e. charging. The proxy=20
    should retain the P-Charging-Function-Addresses or P-Charging-
    Vector header in the outbound message. If the next hop for the=20
    message is outside the closed network of the proxy, then the proxy=20
    shall remove the P-Charging-Function-Addresses and P-Charging-
    Vector headers from the message.    =20
    =20
 5.3 Procedures at the Back to Back UA =20
        =20
    If a B2BUA that understands the P-Charging-Function-Addresses=20
    header or P-Charging-Vector header receives a request/response with =

    the P-Charging-Function-Addresses or P-Charging-Vector header, the=20
    B2BUA  should copy them from the receiving side UA to the sending=20
    side UA. =20
    =20
 5.4 Examples of Usage =20
        =20
    We present example in the context of the scenario presented in the=20
    Background section earlier in this document.  The network diagram=20
    is replicated below:=20
    =20
       Scenario=20
    =20
    =20
    =20
       UA1----P1-----P2-----UA2=20
    =20
    =20
    =20
    This example shows the message sequence for an INVITE transaction=20
    originating from UA1 eventually arriving at UA2. P1 is an outbound=20
    proxy for UA1. In this case P1 also inserts charging information.=20
    P1 then routes the call via P2 to UA2.=20
    =20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 5]=20
=0C         Private SIP Extension for Mobile Charging Information=20
                                May 2002=20
 =20
 =20
    Message sequence for INVITE using P-Charging-Function-Addresses and =

    P-Charging-Vector:=20
    =20
        F1 INVITE UA1 -> P1=20
          INVITE sip:joe  SIP/2.0=20
          Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20
          To: Joe <sip:joe>=20
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=3D456248=20
          Call-ID: 843817637684230@998sdasdh09=20
          CSeq: 18 INVITE=20
          Contact: <sip:UA@192.0.2.4>=20
            . . .=20
    =20
        F2 INVITE P1 -> P2=20
          INVITE sip:joe  SIP/2.0=20
          Via: SIP/2.0/UDP P1:5060;branch=3Dz9hG4bK34ghi7ab04=20
          Via: SIP/2.0/UDP 192.0.2.4:5060;branch=3Dz9hG4bKnashds7=20
          To: Joe <sip:joe>=20
          From: UA@HOMEDOMAIN <UA@HOMEDOMAIN>;tag=3D456248=20
          Call-ID: 843817637684230@998sdasdh09=20
          CSeq: 18 INVITE=20
          Contact: <sip:UA@192.0.2.4>=20
          P-Charging-Function-Addresses:=20
                 primary-ccf=3Dchoice1@HOMEDOMAIN,=20
                 secondary-ccf=3Dchoice2@HOMEDOMAIN=20
          P-Charging-Vector:icid=3D1234bc9876e,=20
                 ioi-originating=3DACCESSDOMAIN=20
                 access-network-charging-info=3DNETWORK-DATA=20
            . . .=20
      =20
 6. Security Considerations =20
        =20
    It is possible for proxies and B2BUAs within a closed network to=20
    modify the value of P-Charging-Function-Addresses and P-Charging-
    Vector or to insert these headers into a request for a dialog, e.g. =

    INVITE request (or other request or response).  It is also possible =

    for proxies on the INVITE path to execute many different attacks. =20
    It is therefore critical to apply transitive mutual authentication=20
    between entities in the closed network, using sips: or other=20
    available mechanisms in order to prevent such attacks.  =20
        =20
 7. IANA Considerations =20
     =20
    This document defines the SIP extension headers "P-Charging-
    Function-Addresses" and "P-Charging-Vector" which should be=20
    included in the registry of SIP headers defined in SIP [1]. As=20
    required by the SIP change process draft-tsvarea-sipchange [4] the=20
    SIP extension header name "Charging-Function-Addresses" and=20
 =20
 =20
 Henrikson              Expires - November 2002               [Page 6]=20
=0C         Private SIP Extension for Mobile Charging Information=20
                                May 2002=20
 =20
 =20
    "Charging-Vector" should also be registered in association with=20
    this extension.=20
        =20
 8. Normative References =20
            =20
    [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,=20
    Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session=20
    Initiation Protocol, RFC 3261", March 2002.=20
    =20
    [2]  D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax=20
    specifications:  ABNF," RFC 2234, Internet Engineering Task Force,=20
    November 1997.=20
    =20
 9. Non-Normative References =20
    =20
    [3]  Garcia, M., et al, "3GPP requirements on SIP,  draft-garcia-
    sipping-3gpp-reqs-03.txt", March 2002.=20
    =20
    [4]  Mankin, A., "SIP Change Process draft-tsvarea-sipchange",=20
    March 2002.=20
    =20
    [5]  3GPP TS 32.200, Version 5, "Telecommunication Management;=20
    Charging management; Charging principles".=20
       =20
 Author's Addresses =20
        =20
    Eric Henrikson=20
    Lucent Technologies=20
    11601 Willows Rd=20
    Suite 100=20
    Redmond, WA  98052=20
    US=20
    =20
    Phone: +1 425 497 2442=20
    EMail: ehenrikson@lucent.com=20
    URI:   http://www.lucent.com/=20
    =20
    =20
    =20
    =20








 =20
 =20
 Henrikson              Expires - November 2002               [Page 7]=20
=0C
------_=_NextPart_000_01C1F5E7.FA990F70--


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



From daemon@optimus.ietf.org  Wed May  8 09:42:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06079
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 09:42:35 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA27992
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 09:42:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26069;
	Wed, 8 May 2002 09:11:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26043
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 09:11:05 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04659
	for <sip@ietf.org>; Wed, 8 May 2002 09:10:56 -0400 (EDT)
From: bernhard.honeisen@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g48DA0Y05406
	for <sip@ietf.org>; Wed, 8 May 2002 16:10:01 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5abd41cf14ac158f2577d@esvir05nok.ntc.nokia.com>;
 Wed, 8 May 2002 16:11:03 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 8 May 2002 16:11:03 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Date: Wed, 8 May 2002 16:11:02 +0300
Message-ID: <E392EEA75EC5F54AB75229B693B1B6A70A5296@esebe018.NOE.Nokia.com>
Thread-Topic: WGLC for draft-willis-sip-path-05: Require:path needed?
Thread-Index: AcH1944mM8TlXyXOSsKsfep6ee8gkAAc1vhAAAYg12AAARtQgA==
To: <hisham.khartabil@nokia.com>, <dean.willis@softarmor.com>,
        <bpenfield@acmepacket.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 08 May 2002 13:11:03.0137 (UTC) FILETIME=[CE16B510:01C1F691]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA26044
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: Khartabil Hisham (NMP/Helsinki) 
> Sent: 08 May, 2002 14:39
> To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com;
> bpenfield@acmepacket.com
> Cc: sip@ietf.org
> Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> needed?
> 
> 
> 
> 
> > -----Original Message-----
> > From: Honeisen Bernhard (NET/Helsinki) 
> > Sent: Wednesday, May 08, 2002 1:33 PM
> > To: dean.willis@softarmor.com; bpenfield@acmepacket.com
> > Cc: sip@ietf.org
> > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> > needed?
> > 
> > 
> > > -----Original Message-----
> > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: 07 May, 2002 21:47
> > > To: 'Bob Penfield'
> > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard
> > > (NET/Helsinki)
> > > Subject: RE: WGLC for draft-willis-sip-path-05: 
> Require:path needed?
> > > 
> > > 
> > > Bob said:
> > > > Maybe I am missing something, but how do we make sure the 
> > > > registrar can support the Path header? The UA probably does 
> > > > not care, but the intervening proxies probably need to know 
> > > > that the "Path" cannot honored by the registrar. I suppose 
> > > > the proxy could insert Require:path if it saw the 
> > > > Supported:path in the request.
> > > > 
> > > > I think the spec should say that UAs that want to allow a 
> > > > Path to be inserted MUST add Supported:path to the REGISTER 
> > > > request and that a proxy MUST NOT add a Path header if 
> > > > Supported:path is not present. The proxy inserting a Path 
> > > > header SHOULD add Require:path to guarantee that the 
> > > > registrar supports Path. If the request is rejected with 420, 
> > > > the UA SHOULD resubmit without Supported:path.
> > > 
> > > I think this works. It does have the side effect that a UA 
> > > that doesn't
> > > know about Path can't be served by a proxy network that 
> > > requires it even
> > > though there are no functional changes needed in the UA.
> > 
> > Do we really want, that the proxies can just insert Paths without
> > the consent of the user? This is related to the first item
> > in the Security considerations section.
> > As the Supported header field can be integrity protected,
> > the registrar has means, to see, whether the UA really
> > knows, what is going on with Path.
> > 
> > Besides this, an implementation of the Path to the UA
> > seams fairly easy.
> > 
> > 
> > My proposal is similar as Bob's:
> > 
> > The registrar ignores any Path header if the Supported:path
> > is not present in that REGISTER request.
> > 
> > A proxy, which inserts a Path header and really wants to stay
> > on the route for incoming calls, inserts also a Require:path
> > (if not yet present).
> > 
> > The registrar decides then based on these two headers, what to do:
> > 
> > - The Require:path has the normal meaning:
> >   -> send 420 response, if registrar does not understood path
> > 
> > - If Supported:path is present in the REGISTER request
> >   --> use path as described in the I/D.
> > 
> > - If Supported:path is _not_ present in the REGISTER request
> >   --> _ignore_ any Path,
> >       regardless of any possible Require:path present
> > 
> > 
> > The only problem I see lasting is, that proxies could prevent
> > a user from registering by just inserting a Require:path.
> > This looks like a more general problem as this can be
> > done with any option tag.
> > 
> > Solution:
> > 
> > -> after a 420 the UA tries to send the request without
> > Supported:path.
> > 
> > -> Proxies MUST NOT insert a Require:path, if no Supported:path
> > was present in the request.
> 
> 
> 
> Are you suggesting that a proxy must remember requests that 
> it processed earlier?

No, not at all. Why do you think it has to remember?

> First you mention that a proxy can insert a path-header 
> without a supported-header (or that is what it sounded like 
> at least).

If it does, the registrar will ignore any Path header, as 
no Supported:path is present in the REGISTER request in
question. Such behaviour would allow easier implementation
of proxies. (But I don't argue, if people think it's better,
if proxies must not insert any Path stuff, if there is
no Supported header in the REGISTER request in question.)
My proposal is just, that the proxy just MUST NOT insert
any Require:path, if Supported:path was not present.

> Then you say that if a 420 is returned to TU, a 

TU ???

> proxy can't insert a path-header in the newly generated 
> request unless a Supported:path is present.

The proxy makes its decision on whether to insert a
Require:path based on the presence of the Supported:path .

> I vote for the supported header to be there from the first 
> REGISTER sent.

What do you mean here?
Do you mean, Supported:path present in first REGISTER attempt,
or do you mean Supported:path present in every REGISTER request?

cheers,
 Bernie

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



From daemon@optimus.ietf.org  Wed May  8 11:09:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11252
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 11:09:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA04434
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 11:09:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02027;
	Wed, 8 May 2002 10:43:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01931
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 10:43:42 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09720
	for <sip@ietf.org>; Wed, 8 May 2002 10:43:32 -0400 (EDT)
From: bernhard.honeisen@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g48Ei2k23766
	for <sip@ietf.org>; Wed, 8 May 2002 17:44:02 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5abd968538ac158f23077@esvir03nok.nokia.com>;
 Wed, 8 May 2002 17:43:34 +0300
Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Wed, 8 May 2002 17:43:40 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Date: Wed, 8 May 2002 17:43:39 +0300
Message-ID: <E392EEA75EC5F54AB75229B693B1B6A70133F029@esebe018.NOE.Nokia.com>
Thread-Topic: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Thread-Index: AcH2nPq53FaSMKJ0RyK0CwgrQfVT5AAAPtTw
To: <bpenfield@acmepacket.com>, <hisham.khartabil@nokia.com>,
        <dean.willis@softarmor.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 08 May 2002 14:43:40.0345 (UTC) FILETIME=[BE715A90:01C1F69E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA01932
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi Bob!

Fair summary. However, I have a slighly different proposal.
Comments inline

cheers,
 Bernie 

> -----Original Message-----
> From: ext Bob Penfield [mailto:bpenfield@acmepacket.com]
> Sent: 08 May, 2002 17:28
> To: Honeisen Bernhard (NET/Helsinki); Khartabil Hisham (NMP/Helsinki);
> dean.willis@softarmor.com
> Cc: sip@ietf.org
> Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> needed?
> 
> 
> I think I agree with Bernie's proposal, but let me summarize 
> the normative
> stuff for clarity.
> 
> 1) A UA that is willing to have Path headers inserted by intervening
> elements(proxies) MUST include Supported:path in the REGISTER request.
> 
> 2) An intervening element MUST NOT add a Path header if 
> Supported:path is
> not present.

What about:
2) An intervening element MUST NOT add a Require:path header and SHOULD
   NOT add a Path header if Supported:path is not present.


> 3) An intervening element that adds a Path (only when 
> Supported:path is
> present) SHOULD insert Require:path (if it is not already present) to
> guarantee that registrar supports 'path'.

What about:
3) An intervening element that adds a Path only when Supported:path
   is present) MAY insert Require:path (if it is not already present) to
   guarantee that registrar supports 'path'.

> 4) A registrar that receives a request with Path headers but does not
> include Supported:path MUST ignore the Path headers. If the registrar
> generated an error response in this case, there would be no 
> way for the UA
> to successfully register assuming that element that illegally 
> added the Path
> header would do it on every REGISTER attempt.
> 
> 5) If a UA gets a 420 response to the REGISTER request with
> Unsupported:path, then it SHOULD re-submit the REGISTER without
> Supported:path. This will prevent any intervening element 
> from adding a path
> or a Require:path (given rule 2) allowing the request to succeed at a
> registrar that does not support 'path'.
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
> 
> ----- Original Message -----
> From: <bernhard.honeisen@nokia.com>
> To: <hisham.khartabil@nokia.com>; <dean.willis@softarmor.com>;
> <bpenfield@acmepacket.com>
> Cc: <sip@ietf.org>
> Sent: Wednesday, May 08, 2002 9:11 AM
> Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> needed?
> 
> 
> 
> 
> > -----Original Message-----
> > From: Khartabil Hisham (NMP/Helsinki)
> > Sent: 08 May, 2002 14:39
> > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com;
> > bpenfield@acmepacket.com
> > Cc: sip@ietf.org
> > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: 
> Require:path
> > needed?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Honeisen Bernhard (NET/Helsinki)
> > > Sent: Wednesday, May 08, 2002 1:33 PM
> > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com
> > > Cc: sip@ietf.org
> > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> > > needed?
> > >
> > >
> > > > -----Original Message-----
> > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > > Sent: 07 May, 2002 21:47
> > > > To: 'Bob Penfield'
> > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; 
> Honeisen Bernhard
> > > > (NET/Helsinki)
> > > > Subject: RE: WGLC for draft-willis-sip-path-05:
> > Require:path needed?
> > > >
> > > >
> > > > Bob said:
> > > > > Maybe I am missing something, but how do we make sure the
> > > > > registrar can support the Path header? The UA probably does
> > > > > not care, but the intervening proxies probably need to know
> > > > > that the "Path" cannot honored by the registrar. I suppose
> > > > > the proxy could insert Require:path if it saw the
> > > > > Supported:path in the request.
> > > > >
> > > > > I think the spec should say that UAs that want to allow a
> > > > > Path to be inserted MUST add Supported:path to the REGISTER
> > > > > request and that a proxy MUST NOT add a Path header if
> > > > > Supported:path is not present. The proxy inserting a Path
> > > > > header SHOULD add Require:path to guarantee that the
> > > > > registrar supports Path. If the request is rejected with 420,
> > > > > the UA SHOULD resubmit without Supported:path.
> > > >
> > > > I think this works. It does have the side effect that a UA
> > > > that doesn't
> > > > know about Path can't be served by a proxy network that
> > > > requires it even
> > > > though there are no functional changes needed in the UA.
> > >
> > > Do we really want, that the proxies can just insert Paths without
> > > the consent of the user? This is related to the first item
> > > in the Security considerations section.
> > > As the Supported header field can be integrity protected,
> > > the registrar has means, to see, whether the UA really
> > > knows, what is going on with Path.
> > >
> > > Besides this, an implementation of the Path to the UA
> > > seams fairly easy.
> > >
> > >
> > > My proposal is similar as Bob's:
> > >
> > > The registrar ignores any Path header if the Supported:path
> > > is not present in that REGISTER request.
> > >
> > > A proxy, which inserts a Path header and really wants to stay
> > > on the route for incoming calls, inserts also a Require:path
> > > (if not yet present).
> > >
> > > The registrar decides then based on these two headers, what to do:
> > >
> > > - The Require:path has the normal meaning:
> > >   -> send 420 response, if registrar does not understood path
> > >
> > > - If Supported:path is present in the REGISTER request
> > >   --> use path as described in the I/D.
> > >
> > > - If Supported:path is _not_ present in the REGISTER request
> > >   --> _ignore_ any Path,
> > >       regardless of any possible Require:path present
> > >
> > >
> > > The only problem I see lasting is, that proxies could prevent
> > > a user from registering by just inserting a Require:path.
> > > This looks like a more general problem as this can be
> > > done with any option tag.
> > >
> > > Solution:
> > >
> > > -> after a 420 the UA tries to send the request without
> > > Supported:path.
> > >
> > > -> Proxies MUST NOT insert a Require:path, if no Supported:path
> > > was present in the request.
> >
> >
> >
> > Are you suggesting that a proxy must remember requests that
> > it processed earlier?
> 
> No, not at all. Why do you think it has to remember?
> 
> > First you mention that a proxy can insert a path-header
> > without a supported-header (or that is what it sounded like
> > at least).
> 
> If it does, the registrar will ignore any Path header, as
> no Supported:path is present in the REGISTER request in
> question. Such behaviour would allow easier implementation
> of proxies. (But I don't argue, if people think it's better,
> if proxies must not insert any Path stuff, if there is
> no Supported header in the REGISTER request in question.)
> My proposal is just, that the proxy just MUST NOT insert
> any Require:path, if Supported:path was not present.
> 
> > Then you say that if a 420 is returned to TU, a
> 
> TU ???
> 
> > proxy can't insert a path-header in the newly generated
> > request unless a Supported:path is present.
> 
> The proxy makes its decision on whether to insert a
> Require:path based on the presence of the Supported:path .
> 
> > I vote for the supported header to be there from the first
> > REGISTER sent.
> 
> What do you mean here?
> Do you mean, Supported:path present in first REGISTER attempt,
> or do you mean Supported:path present in every REGISTER request?
> 
> cheers,
>  Bernie
> 
> 
> 

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



From daemon@optimus.ietf.org  Wed May  8 11:24:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12332
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 11:24:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA05898
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 11:24:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00837;
	Wed, 8 May 2002 10:31:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00795
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 10:30:56 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09130
	for <sip@ietf.org>; Wed, 8 May 2002 10:30:47 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A69FF76C00D8; Wed, 08 May 2002 10:30:55 -0400
Message-ID: <004701c1f69c$8039fea0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <bernhard.honeisen@nokia.com>, <hisham.khartabil@nokia.com>,
        <dean.willis@softarmor.com>
Cc: <sip@ietf.org>
References: <E392EEA75EC5F54AB75229B693B1B6A70A5296@esebe018.NOE.Nokia.com>
Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Date: Wed, 8 May 2002 10:27:36 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I think I agree with Bernie's proposal, but let me summarize the normative
stuff for clarity.

1) A UA that is willing to have Path headers inserted by intervening
elements(proxies) MUST include Supported:path in the REGISTER request.

2) An intervening element MUST NOT add a Path header if Supported:path is
not present.

3) An intervening element that adds a Path (only when Supported:path is
present) SHOULD insert Require:path (if it is not already present) to
guarantee that registrar supports 'path'.

4) A registrar that receives a request with Path headers but does not
include Supported:path MUST ignore the Path headers. If the registrar
generated an error response in this case, there would be no way for the UA
to successfully register assuming that element that illegally added the Path
header would do it on every REGISTER attempt.

5) If a UA gets a 420 response to the REGISTER request with
Unsupported:path, then it SHOULD re-submit the REGISTER without
Supported:path. This will prevent any intervening element from adding a path
or a Require:path (given rule 2) allowing the request to succeed at a
registrar that does not support 'path'.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: <bernhard.honeisen@nokia.com>
To: <hisham.khartabil@nokia.com>; <dean.willis@softarmor.com>;
<bpenfield@acmepacket.com>
Cc: <sip@ietf.org>
Sent: Wednesday, May 08, 2002 9:11 AM
Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
needed?




> -----Original Message-----
> From: Khartabil Hisham (NMP/Helsinki)
> Sent: 08 May, 2002 14:39
> To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com;
> bpenfield@acmepacket.com
> Cc: sip@ietf.org
> Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> needed?
>
>
>
>
> > -----Original Message-----
> > From: Honeisen Bernhard (NET/Helsinki)
> > Sent: Wednesday, May 08, 2002 1:33 PM
> > To: dean.willis@softarmor.com; bpenfield@acmepacket.com
> > Cc: sip@ietf.org
> > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> > needed?
> >
> >
> > > -----Original Message-----
> > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > Sent: 07 May, 2002 21:47
> > > To: 'Bob Penfield'
> > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; Honeisen Bernhard
> > > (NET/Helsinki)
> > > Subject: RE: WGLC for draft-willis-sip-path-05:
> Require:path needed?
> > >
> > >
> > > Bob said:
> > > > Maybe I am missing something, but how do we make sure the
> > > > registrar can support the Path header? The UA probably does
> > > > not care, but the intervening proxies probably need to know
> > > > that the "Path" cannot honored by the registrar. I suppose
> > > > the proxy could insert Require:path if it saw the
> > > > Supported:path in the request.
> > > >
> > > > I think the spec should say that UAs that want to allow a
> > > > Path to be inserted MUST add Supported:path to the REGISTER
> > > > request and that a proxy MUST NOT add a Path header if
> > > > Supported:path is not present. The proxy inserting a Path
> > > > header SHOULD add Require:path to guarantee that the
> > > > registrar supports Path. If the request is rejected with 420,
> > > > the UA SHOULD resubmit without Supported:path.
> > >
> > > I think this works. It does have the side effect that a UA
> > > that doesn't
> > > know about Path can't be served by a proxy network that
> > > requires it even
> > > though there are no functional changes needed in the UA.
> >
> > Do we really want, that the proxies can just insert Paths without
> > the consent of the user? This is related to the first item
> > in the Security considerations section.
> > As the Supported header field can be integrity protected,
> > the registrar has means, to see, whether the UA really
> > knows, what is going on with Path.
> >
> > Besides this, an implementation of the Path to the UA
> > seams fairly easy.
> >
> >
> > My proposal is similar as Bob's:
> >
> > The registrar ignores any Path header if the Supported:path
> > is not present in that REGISTER request.
> >
> > A proxy, which inserts a Path header and really wants to stay
> > on the route for incoming calls, inserts also a Require:path
> > (if not yet present).
> >
> > The registrar decides then based on these two headers, what to do:
> >
> > - The Require:path has the normal meaning:
> >   -> send 420 response, if registrar does not understood path
> >
> > - If Supported:path is present in the REGISTER request
> >   --> use path as described in the I/D.
> >
> > - If Supported:path is _not_ present in the REGISTER request
> >   --> _ignore_ any Path,
> >       regardless of any possible Require:path present
> >
> >
> > The only problem I see lasting is, that proxies could prevent
> > a user from registering by just inserting a Require:path.
> > This looks like a more general problem as this can be
> > done with any option tag.
> >
> > Solution:
> >
> > -> after a 420 the UA tries to send the request without
> > Supported:path.
> >
> > -> Proxies MUST NOT insert a Require:path, if no Supported:path
> > was present in the request.
>
>
>
> Are you suggesting that a proxy must remember requests that
> it processed earlier?

No, not at all. Why do you think it has to remember?

> First you mention that a proxy can insert a path-header
> without a supported-header (or that is what it sounded like
> at least).

If it does, the registrar will ignore any Path header, as
no Supported:path is present in the REGISTER request in
question. Such behaviour would allow easier implementation
of proxies. (But I don't argue, if people think it's better,
if proxies must not insert any Path stuff, if there is
no Supported header in the REGISTER request in question.)
My proposal is just, that the proxy just MUST NOT insert
any Require:path, if Supported:path was not present.

> Then you say that if a 420 is returned to TU, a

TU ???

> proxy can't insert a path-header in the newly generated
> request unless a Supported:path is present.

The proxy makes its decision on whether to insert a
Require:path based on the presence of the Supported:path .

> I vote for the supported header to be there from the first
> REGISTER sent.

What do you mean here?
Do you mean, Supported:path present in first REGISTER attempt,
or do you mean Supported:path present in every REGISTER request?

cheers,
 Bernie



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



From daemon@optimus.ietf.org  Wed May  8 12:04:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14465
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 12:04:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA10515
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 12:04:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05865;
	Wed, 8 May 2002 11:23:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05834
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 11:23:44 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12289
	for <sip@ietf.org>; Wed, 8 May 2002 11:23:37 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A2FFAC070110; Wed, 08 May 2002 11:23:43 -0400
Message-ID: <007b01c1f6a3$e0667e00$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <bernhard.honeisen@nokia.com>, <hisham.khartabil@nokia.com>,
        <dean.willis@softarmor.com>
Cc: <sip@ietf.org>
References: <E392EEA75EC5F54AB75229B693B1B6A70133F029@esebe018.NOE.Nokia.com>
Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Date: Wed, 8 May 2002 11:20:24 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


> ----- Original Message -----
> From: <bernhard.honeisen@nokia.com>
> <snip>
> > -----Original Message-----
> > From: ext Bob Penfield [mailto:bpenfield@acmepacket.com]
> <snip>
> > 2) An intervening element MUST NOT add a Path header if
> > Supported:path is
> > not present.
>
> What about:
> 2) An intervening element MUST NOT add a Require:path header and SHOULD
>    NOT add a Path header if Supported:path is not present.

Given rule 4, any Path header inserted by the proxy will be ignored by the
registrar. I see no reason to make this a SHOULD NOT instead of a MUST NOT.
It all goes back to the "knowledge and consent of the user" requirements.

>
> > 3) An intervening element that adds a Path (only when
> > Supported:path is
> > present) SHOULD insert Require:path (if it is not already present) to
> > guarantee that registrar supports 'path'.
>
> What about:
> 3) An intervening element that adds a Path only when Supported:path
>    is present) MAY insert Require:path (if it is not already present) to
>    guarantee that registrar supports 'path'.

The only reason you would not include it is if you were sure that the
registrar supported it or you did not care. For an implementation
requirement, I think SHOULD is appropriate. Certainly an implementation can
have a configuration option to prevent the addition of Require:path. Maybe
you could include a recommendation that it be configurable.

>
> > 4) A registrar that receives a request with Path headers but does not
> > include Supported:path MUST ignore the Path headers. If the registrar
> > generated an error response in this case, there would be no
> > way for the UA
> > to successfully register assuming that element that illegally
> > added the Path
> > header would do it on every REGISTER attempt.
> >
> > 5) If a UA gets a 420 response to the REGISTER request with
> > Unsupported:path, then it SHOULD re-submit the REGISTER without
> > Supported:path. This will prevent any intervening element
> > from adding a path
> > or a Require:path (given rule 2) allowing the request to succeed at a
> > registrar that does not support 'path'.
> >



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



From daemon@optimus.ietf.org  Wed May  8 12:44:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16070
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 12:44:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA13422
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 12:44:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08750;
	Wed, 8 May 2002 11:53:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08723
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 11:53:38 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14138
	for <sip@ietf.org>; Wed, 8 May 2002 11:53:30 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g48FquP00910
	for <sip@ietf.org>; Wed, 8 May 2002 11:52:56 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id KAA26208; Wed, 8 May 2002 10:52:55 -0500 (CDT)
Message-ID: <3CD949D5.7080907@lucent.com>
Date: Wed, 08 May 2002 10:52:53 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: SIP LIST <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Repost: Timer C, Timer B and Spiraling
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Since most people were busy with the interim SIP WG meeting, I did not
hear from anyone on the list, I will send this out again...

Some comments on -09bis on Timers C, B, and spiraling:

1) In SIP, proxies can fork either in serial or in parallel.  Consider
    serial forking for this discussion.  Normally, in the presence of
    multiple Contact headers to an address-of-record, a proxy will sort
    the Contacts based on their q value and fork serially to each
    Contact.  If Contact 1 did not elicit a final response within a
    certain time, Contact 2 will be tried, and so on.  Problem is,
    what exactly is the time for a proxy to give up on the current
    Contact and try the next one?

    Reading -09bis, it appears that timer C can serve this function.
    But the initial value of timer C is too high (3 minutes, and it is
    a MUST to set it to at least 3 mins), so that will not work.  Another
    possible candidate is the transaction timeout; if a proxy allows a
    client transaction to continue (T1*64 seconds = 32 seconds) until it
    times out, the time between trying the next Contact (32 seconds) is
    too large for the caller to keep holding.  So, this does not work
    either.

    Should -09bis provide some guidance on timers to use in proxy cores
    if serial forking is being used and > 1 Contact header is present,
    or should this be left upto the implementer?

2) Timer B controls transaction timeouts in INVITE client trans-
    actions.  The state diagram in Figure 5 is silent on what to
    do if Timer B fires while control is in "Proceeding" state; i.e.
    received a 180, but no final response.  The correct behavior
    should be to sent a CANCEL and enter "Terminated" state.

3) Regarding finding the spiraled R-R on responses in order to
    modify it (section 16.7, step 8), won't it be the case that
    the first R-R in a response corresponds to the inner-most
    spiral?  Since the inner-most spiral will generate the first
    response, can't we just get the first R-R header on a response
    in order to modify it?

If I mis-represented something and the solution is in -09bis, please
let me know.

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216


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



From daemon@optimus.ietf.org  Wed May  8 12:55:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16338
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 12:55:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA14241
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 12:55:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11685;
	Wed, 8 May 2002 12:16:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11654
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 12:16:26 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15160
	for <sip@ietf.org>; Wed, 8 May 2002 12:16:18 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g48GFod29654;
	Wed, 8 May 2002 11:15:50 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>, <bernhard.honeisen@nokia.com>,
        <hisham.khartabil@nokia.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Date: Wed, 8 May 2002 11:15:40 -0500
Message-ID: <005201c1f6ab$99ab5eb0$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <004701c1f69c$8039fea0$2300000a@acmepacket.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


The only problem with this is that there may well be proxies that know
that if Path isn't used, then registering through that proxy will fail.
It seems that these proxies legitimately REQUIRE the Path extension,
since if it is not supported, they will not function.

So if a UA tries to register without Supported:path through such a
proxy, we need to be able to reject it.

--
Dean

> -----Original Message-----
> From: Bob Penfield [mailto:bpenfield@acmepacket.com] 
> Sent: Wednesday, May 08, 2002 9:28 AM
> To: bernhard.honeisen@nokia.com; hisham.khartabil@nokia.com; 
> dean.willis@softarmor.com
> Cc: sip@ietf.org
> Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: 
> Require:path needed?
> 
> 
> I think I agree with Bernie's proposal, but let me summarize 
> the normative stuff for clarity.
> 
> 1) A UA that is willing to have Path headers inserted by intervening
> elements(proxies) MUST include Supported:path in the REGISTER request.
> 
> 2) An intervening element MUST NOT add a Path header if 
> Supported:path is not present.
> 
> 3) An intervening element that adds a Path (only when 
> Supported:path is
> present) SHOULD insert Require:path (if it is not already 
> present) to guarantee that registrar supports 'path'.
> 
> 4) A registrar that receives a request with Path headers but 
> does not include Supported:path MUST ignore the Path headers. 
> If the registrar generated an error response in this case, 
> there would be no way for the UA to successfully register 
> assuming that element that illegally added the Path header 
> would do it on every REGISTER attempt.
> 
> 5) If a UA gets a 420 response to the REGISTER request with 
> Unsupported:path, then it SHOULD re-submit the REGISTER 
> without Supported:path. This will prevent any intervening 
> element from adding a path or a Require:path (given rule 2) 
> allowing the request to succeed at a registrar that does not 
> support 'path'.
> 
> cheers,
> (-:bob
> 
> Robert F. Penfield
> Chief Software Architect
> Acme Packet, Inc.
> 130 New Boston Street
> Woburn, MA 01801
> bpenfield@acmepacket.com
> 
> ----- Original Message -----
> From: <bernhard.honeisen@nokia.com>
> To: <hisham.khartabil@nokia.com>; 
> <dean.willis@softarmor.com>; <bpenfield@acmepacket.com>
> Cc: <sip@ietf.org>
> Sent: Wednesday, May 08, 2002 9:11 AM
> Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: 
> Require:path needed?
> 
> 
> 
> 
> > -----Original Message-----
> > From: Khartabil Hisham (NMP/Helsinki)
> > Sent: 08 May, 2002 14:39
> > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com; 
> > bpenfield@acmepacket.com
> > Cc: sip@ietf.org
> > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: 
> Require:path 
> > needed?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Honeisen Bernhard (NET/Helsinki)
> > > Sent: Wednesday, May 08, 2002 1:33 PM
> > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com
> > > Cc: sip@ietf.org
> > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: 
> Require:path 
> > > needed?
> > >
> > >
> > > > -----Original Message-----
> > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > > Sent: 07 May, 2002 21:47
> > > > To: 'Bob Penfield'
> > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org; 
> Honeisen Bernhard
> > > > (NET/Helsinki)
> > > > Subject: RE: WGLC for draft-willis-sip-path-05:
> > Require:path needed?
> > > >
> > > >
> > > > Bob said:
> > > > > Maybe I am missing something, but how do we make sure the 
> > > > > registrar can support the Path header? The UA 
> probably does not 
> > > > > care, but the intervening proxies probably need to 
> know that the 
> > > > > "Path" cannot honored by the registrar. I suppose the proxy 
> > > > > could insert Require:path if it saw the Supported:path in the 
> > > > > request.
> > > > >
> > > > > I think the spec should say that UAs that want to 
> allow a Path 
> > > > > to be inserted MUST add Supported:path to the 
> REGISTER request 
> > > > > and that a proxy MUST NOT add a Path header if 
> Supported:path is 
> > > > > not present. The proxy inserting a Path header SHOULD add 
> > > > > Require:path to guarantee that the registrar supports 
> Path. If 
> > > > > the request is rejected with 420, the UA SHOULD 
> resubmit without 
> > > > > Supported:path.
> > > >
> > > > I think this works. It does have the side effect that a UA that 
> > > > doesn't know about Path can't be served by a proxy network that
> > > > requires it even
> > > > though there are no functional changes needed in the UA.
> > >
> > > Do we really want, that the proxies can just insert Paths without 
> > > the consent of the user? This is related to the first item in the 
> > > Security considerations section. As the Supported header 
> field can 
> > > be integrity protected, the registrar has means, to see, 
> whether the 
> > > UA really knows, what is going on with Path.
> > >
> > > Besides this, an implementation of the Path to the UA
> > > seams fairly easy.
> > >
> > >
> > > My proposal is similar as Bob's:
> > >
> > > The registrar ignores any Path header if the 
> Supported:path is not 
> > > present in that REGISTER request.
> > >
> > > A proxy, which inserts a Path header and really wants to 
> stay on the 
> > > route for incoming calls, inserts also a Require:path (if not yet 
> > > present).
> > >
> > > The registrar decides then based on these two headers, what to do:
> > >
> > > - The Require:path has the normal meaning:
> > >   -> send 420 response, if registrar does not understood path
> > >
> > > - If Supported:path is present in the REGISTER request
> > >   --> use path as described in the I/D.
> > >
> > > - If Supported:path is _not_ present in the REGISTER request
> > >   --> _ignore_ any Path,
> > >       regardless of any possible Require:path present
> > >
> > >
> > > The only problem I see lasting is, that proxies could 
> prevent a user 
> > > from registering by just inserting a Require:path. This 
> looks like a 
> > > more general problem as this can be done with any option tag.
> > >
> > > Solution:
> > >
> > > -> after a 420 the UA tries to send the request without
> > > Supported:path.
> > >
> > > -> Proxies MUST NOT insert a Require:path, if no Supported:path
> > > was present in the request.
> >
> >
> >
> > Are you suggesting that a proxy must remember requests that it 
> > processed earlier?
> 
> No, not at all. Why do you think it has to remember?
> 
> > First you mention that a proxy can insert a path-header without a 
> > supported-header (or that is what it sounded like at least).
> 
> If it does, the registrar will ignore any Path header, as
> no Supported:path is present in the REGISTER request in 
> question. Such behaviour would allow easier implementation of 
> proxies. (But I don't argue, if people think it's better, if 
> proxies must not insert any Path stuff, if there is no 
> Supported header in the REGISTER request in question.) My 
> proposal is just, that the proxy just MUST NOT insert any 
> Require:path, if Supported:path was not present.
> 
> > Then you say that if a 420 is returned to TU, a
> 
> TU ???
> 
> > proxy can't insert a path-header in the newly generated 
> request unless 
> > a Supported:path is present.
> 
> The proxy makes its decision on whether to insert a 
> Require:path based on the presence of the Supported:path .
> 
> > I vote for the supported header to be there from the first REGISTER 
> > sent.
> 
> What do you mean here?
> Do you mean, Supported:path present in first REGISTER 
> attempt, or do you mean Supported:path present in every 
> REGISTER request?
> 
> cheers,
>  Bernie
> 
> 
> 


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



From daemon@optimus.ietf.org  Wed May  8 13:05:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16606
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 13:05:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA15163
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 13:05:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10649;
	Wed, 8 May 2002 12:06:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10618
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 12:06:47 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14571
	for <sip@ietf.org>; Wed, 8 May 2002 12:06:39 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g48G6Cd29576;
	Wed, 8 May 2002 11:06:12 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <bernhard.honeisen@nokia.com>, <bpenfield@acmepacket.com>
Cc: <sip@ietf.org>
Date: Wed, 8 May 2002 11:06:00 -0500
Message-ID: <003601c1f6aa$40baed30$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <E392EEA75EC5F54AB75229B693B1B6A70A5294@esebe018.NOE.Nokia.com>
Content-Transfer-Encoding: 7bit
Subject: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> My proposal is similar as Bob's:
> 
> The registrar ignores any Path header if the Supported:path
> is not present in that REGISTER request.
> 
> A proxy, which inserts a Path header and really wants to stay 
> on the route for incoming calls, inserts also a Require:path 
> (if not yet present).
> 
> The registrar decides then based on these two headers, what to do:
> 
> - The Require:path has the normal meaning:
>   -> send 420 response, if registrar does not understood path
> 
> - If Supported:path is present in the REGISTER request
>   --> use path as described in the I/D.
> 
> - If Supported:path is _not_ present in the REGISTER request
>   --> _ignore_ any Path,
>       regardless of any possible Require:path present
> 
> 
> The only problem I see lasting is, that proxies could prevent
> a user from registering by just inserting a Require:path.
> This looks like a more general problem as this can be
> done with any option tag.
> 
> Solution:
> 
> -> after a 420 the UA tries to send the request without
> Supported:path.
> 
> -> Proxies MUST NOT insert a Require:path, if no Supported:path
> was present in the request.
> 
> 
> Comments?
> 
> cheers,
>  Bernie
> 

I believe this works. 

--
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 daemon@optimus.ietf.org  Wed May  8 13:45:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18255
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 13:45:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA17635
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 13:46:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15151;
	Wed, 8 May 2002 13:05:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15119
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 13:05:07 -0400 (EDT)
Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16597
	for <sip@ietf.org>; Wed, 8 May 2002 13:04:55 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 8 May 2002 12:04:27 -0500
Message-ID: <CD110021698980419241042CF576B8F2014C3033@EXCALIBUR.santera.com>
Thread-Topic: Question regarding draft-ietf-sip-cc-transfer-05
thread-index: AcH2smcK2WEwQgilQnKOWwcp54sJAA==
From: "Chiou, Mark" <MChiou@Santera.com>
To: <rsparks@dynamicsoft.com>
Cc: <sip@ietf.org>, "Sridhar Kuppanna" <sridhar_03@yahoo.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA15120
Subject: [Sip] Question regarding draft-ietf-sip-cc-transfer-05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi Robert,

This is a question regarding Call transfer successful scenario.

In the Call transfer draft, section 4, it mentions the connection between transferor and the transferee MUST be maintained in case of un-successful cases. (i.e. No answer, busy, & etc.), such that the transferor has the ability to retreat the call back.

In section 5, it mentions "Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request." 

The questions are :

1) neither party (transferor or the transferee) physically hits an "end" key to release the call, then the session will not be released. Is it what we want? It wastes resources.

2) each party (transferor or transferee) can send a re-INVITE request message to get the conversation back. It is different behavior than the PSTN network. (In the existing call transfer, especially PSTN network, the connection between transferor and the transferee is released.)

3) If the transferee sends a re-INVITE request message to the transferor, does it become a 3-way call? 

Here is my penny thought, Can we change the note in section 5 as" the User Agent application for the transferor SHALL automatically send a subsequent BYE request message to release the session between the transferor and the transferee"? For transferee, we might say " the User Agent application for the transferee MAY automatically send a subsequent BYE request message to release the session between the transferor and the transferee."

By the way, I do not have problem for a PSTN user as the transferor because the PSTN network (i.e. switch) will ensure the disconnect, which is mapped to a BYE request message for the IP network. The same behavior is used for MGCP user too. The only problem is in SIP environment (i.e. Transferor, transferee and transfer Target are SIP phones), which requires an extra step to release the session.

Regards,

Mark Chiou


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



From daemon@optimus.ietf.org  Wed May  8 14:36:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19831
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 14:36:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA20554
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 14:36:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19057;
	Wed, 8 May 2002 14:08:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19028
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 14:08:34 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19155
	for <sip@ietf.org>; Wed, 8 May 2002 14:08:25 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A99DF89A0110; Wed, 08 May 2002 14:08:29 -0400
Message-ID: <003901c1f6ba$e1c33060$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Dean Willis" <dean.willis@softarmor.com>, <bernhard.honeisen@nokia.com>,
        <hisham.khartabil@nokia.com>
Cc: <sip@ietf.org>
References: <005201c1f6ab$99ab5eb0$4a010114@TXDWILLIS2>
Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Date: Wed, 8 May 2002 14:05:05 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Dean Willis" <dean.willis@softarmor.com>

>
> The only problem with this is that there may well be proxies that know
> that if Path isn't used, then registering through that proxy will fail.
> It seems that these proxies legitimately REQUIRE the Path extension,
> since if it is not supported, they will not function.
>
> So if a UA tries to register without Supported:path through such a
> proxy, we need to be able to reject it.

Absolutely. Rule #2 does not require the proxy to pass on the request. But
it should be modified to say that the proxy can reject the request with 421
and Require:path if it instists on being in the path.

> --
> Dean
>
> > -----Original Message-----
> > From: Bob Penfield [mailto:bpenfield@acmepacket.com]
> > Sent: Wednesday, May 08, 2002 9:28 AM
> > To: bernhard.honeisen@nokia.com; hisham.khartabil@nokia.com;
> > dean.willis@softarmor.com
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] RE: WGLC for draft-willis-sip-path-05:
> > Require:path needed?
> >
> >
> > I think I agree with Bernie's proposal, but let me summarize
> > the normative stuff for clarity.
> >
> > 1) A UA that is willing to have Path headers inserted by intervening
> > elements(proxies) MUST include Supported:path in the REGISTER request.
> >
> > 2) An intervening element MUST NOT add a Path header if
> > Supported:path is not present.
> >
> > 3) An intervening element that adds a Path (only when
> > Supported:path is
> > present) SHOULD insert Require:path (if it is not already
> > present) to guarantee that registrar supports 'path'.
> >
> > 4) A registrar that receives a request with Path headers but
> > does not include Supported:path MUST ignore the Path headers.
> > If the registrar generated an error response in this case,
> > there would be no way for the UA to successfully register
> > assuming that element that illegally added the Path header
> > would do it on every REGISTER attempt.
> >
> > 5) If a UA gets a 420 response to the REGISTER request with
> > Unsupported:path, then it SHOULD re-submit the REGISTER
> > without Supported:path. This will prevent any intervening
> > element from adding a path or a Require:path (given rule 2)
> > allowing the request to succeed at a registrar that does not
> > support 'path'.
> >
> > cheers,
> > (-:bob
> >
> > Robert F. Penfield
> > Chief Software Architect
> > Acme Packet, Inc.
> > 130 New Boston Street
> > Woburn, MA 01801
> > bpenfield@acmepacket.com
> >
> > ----- Original Message -----
> > From: <bernhard.honeisen@nokia.com>
> > To: <hisham.khartabil@nokia.com>;
> > <dean.willis@softarmor.com>; <bpenfield@acmepacket.com>
> > Cc: <sip@ietf.org>
> > Sent: Wednesday, May 08, 2002 9:11 AM
> > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05:
> > Require:path needed?
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Khartabil Hisham (NMP/Helsinki)
> > > Sent: 08 May, 2002 14:39
> > > To: Honeisen Bernhard (NET/Helsinki); dean.willis@softarmor.com;
> > > bpenfield@acmepacket.com
> > > Cc: sip@ietf.org
> > > Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05:
> > Require:path
> > > needed?
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Honeisen Bernhard (NET/Helsinki)
> > > > Sent: Wednesday, May 08, 2002 1:33 PM
> > > > To: dean.willis@softarmor.com; bpenfield@acmepacket.com
> > > > Cc: sip@ietf.org
> > > > Subject: [Sip] RE: WGLC for draft-willis-sip-path-05:
> > Require:path
> > > > needed?
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> > > > > Sent: 07 May, 2002 21:47
> > > > > To: 'Bob Penfield'
> > > > > Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;
> > Honeisen Bernhard
> > > > > (NET/Helsinki)
> > > > > Subject: RE: WGLC for draft-willis-sip-path-05:
> > > Require:path needed?
> > > > >
> > > > >
> > > > > Bob said:
> > > > > > Maybe I am missing something, but how do we make sure the
> > > > > > registrar can support the Path header? The UA
> > probably does not
> > > > > > care, but the intervening proxies probably need to
> > know that the
> > > > > > "Path" cannot honored by the registrar. I suppose the proxy
> > > > > > could insert Require:path if it saw the Supported:path in the
> > > > > > request.
> > > > > >
> > > > > > I think the spec should say that UAs that want to
> > allow a Path
> > > > > > to be inserted MUST add Supported:path to the
> > REGISTER request
> > > > > > and that a proxy MUST NOT add a Path header if
> > Supported:path is
> > > > > > not present. The proxy inserting a Path header SHOULD add
> > > > > > Require:path to guarantee that the registrar supports
> > Path. If
> > > > > > the request is rejected with 420, the UA SHOULD
> > resubmit without
> > > > > > Supported:path.
> > > > >
> > > > > I think this works. It does have the side effect that a UA that
> > > > > doesn't know about Path can't be served by a proxy network that
> > > > > requires it even
> > > > > though there are no functional changes needed in the UA.
> > > >
> > > > Do we really want, that the proxies can just insert Paths without
> > > > the consent of the user? This is related to the first item in the
> > > > Security considerations section. As the Supported header
> > field can
> > > > be integrity protected, the registrar has means, to see,
> > whether the
> > > > UA really knows, what is going on with Path.
> > > >
> > > > Besides this, an implementation of the Path to the UA
> > > > seams fairly easy.
> > > >
> > > >
> > > > My proposal is similar as Bob's:
> > > >
> > > > The registrar ignores any Path header if the
> > Supported:path is not
> > > > present in that REGISTER request.
> > > >
> > > > A proxy, which inserts a Path header and really wants to
> > stay on the
> > > > route for incoming calls, inserts also a Require:path (if not yet
> > > > present).
> > > >
> > > > The registrar decides then based on these two headers, what to do:
> > > >
> > > > - The Require:path has the normal meaning:
> > > >   -> send 420 response, if registrar does not understood path
> > > >
> > > > - If Supported:path is present in the REGISTER request
> > > >   --> use path as described in the I/D.
> > > >
> > > > - If Supported:path is _not_ present in the REGISTER request
> > > >   --> _ignore_ any Path,
> > > >       regardless of any possible Require:path present
> > > >
> > > >
> > > > The only problem I see lasting is, that proxies could
> > prevent a user
> > > > from registering by just inserting a Require:path. This
> > looks like a
> > > > more general problem as this can be done with any option tag.
> > > >
> > > > Solution:
> > > >
> > > > -> after a 420 the UA tries to send the request without
> > > > Supported:path.
> > > >
> > > > -> Proxies MUST NOT insert a Require:path, if no Supported:path
> > > > was present in the request.
> > >
> > >
> > >
> > > Are you suggesting that a proxy must remember requests that it
> > > processed earlier?
> >
> > No, not at all. Why do you think it has to remember?
> >
> > > First you mention that a proxy can insert a path-header without a
> > > supported-header (or that is what it sounded like at least).
> >
> > If it does, the registrar will ignore any Path header, as
> > no Supported:path is present in the REGISTER request in
> > question. Such behaviour would allow easier implementation of
> > proxies. (But I don't argue, if people think it's better, if
> > proxies must not insert any Path stuff, if there is no
> > Supported header in the REGISTER request in question.) My
> > proposal is just, that the proxy just MUST NOT insert any
> > Require:path, if Supported:path was not present.
> >
> > > Then you say that if a 420 is returned to TU, a
> >
> > TU ???
> >
> > > proxy can't insert a path-header in the newly generated
> > request unless
> > > a Supported:path is present.
> >
> > The proxy makes its decision on whether to insert a
> > Require:path based on the presence of the Supported:path .
> >
> > > I vote for the supported header to be there from the first REGISTER
> > > sent.
> >
> > What do you mean here?
> > Do you mean, Supported:path present in first REGISTER
> > attempt, or do you mean Supported:path present in every
> > REGISTER request?
> >
> > cheers,
> >  Bernie
> >
> >
> >
>
>


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



From daemon@optimus.ietf.org  Wed May  8 21:13:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27795
	for <sip-archive@odin.ietf.org>; Wed, 8 May 2002 21:13:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA10148
	for sip-archive@odin.ietf.org; Wed, 8 May 2002 21:13:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07709;
	Wed, 8 May 2002 20:25:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07683
	for <sip@optimus.ietf.org>; Wed, 8 May 2002 20:25:32 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27043;
	Wed, 8 May 2002 20:25:22 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g490Oxd32314;
	Wed, 8 May 2002 19:24:59 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <minutes@ietf.org>
Date: Wed, 8 May 2002 19:24:43 -0500
Message-ID: <002601c1f6ef$ebb0be50$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Notes from SIP Working Group Interim Meeting, May 6-7, 2002
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I've posted the various notes I received at:

http://www.softarmor.com/sipwg/meets/interim-may-02/notes/

If you want your slides posted, please send them to me.

--
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 daemon@optimus.ietf.org  Thu May  9 07:33:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16004
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 07:33:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA19234
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 07:33:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18098;
	Thu, 9 May 2002 07:14:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18071
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 07:14:42 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15785
	for <sip@ietf.org>; Thu, 9 May 2002 07:14:33 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g49BEaA26197
	for <sip@ietf.org>; Thu, 9 May 2002 07:14:36 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <KRL3YN0V>; Thu, 9 May 2002 12:14:35 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB004FE92C8@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Dean Willis <dean.willis@softarmor.com>, jh@lohi.eng.song.fi
Cc: sip@ietf.org, "'3GPP_TSG_CN_WG1'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        bernhard.honeisen@nokia.com, "'Rohan Mahy'" <rohan@cisco.com>,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: RE: [Sip] WGLC for draft-willis-sip-path-05
Date: Thu, 9 May 2002 12:14:33 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

I not not sure that deletion solves the problem. We still need to retain
text that the usage of this information from the REGISTER response in the UA
is outside the scope of the specification.

Or is that recorded somewhere else?

Keith

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 07 May 2002 18:39
> To: jh@lohi.eng.song.fi
> Cc: sip@ietf.org; '3GPP_TSG_CN_WG1'; 
> bernhard.honeisen@nokia.com; 'Rohan
> Mahy'; brian.rosen@marconi.com; jo@ipdialog.com
> Subject: RE: [Sip] WGLC for draft-willis-sip-path-05
> 
> 
> 
> 
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> > Behalf Of jh@lohi.eng.song.fi
> > Sent: Monday, May 06, 2002 3:06 AM
> > To: Dean Willis
> > Cc: sip@ietf.org; 3GPP_TSG_CN_WG1; 
> > bernhard.honeisen@nokia.com; Rohan Mahy; 
> > brian.rosen@marconi.com; jo@ipdialog.com
> > Subject: [Sip] WGLC for draft-willis-sip-path-05
> > 
> > 
> > below are my comments:
> > 
> > - i thought that it was agreed to use name rrr instead of 
> > path for this
> >   header.  the reason is that this header is both semantically and
> >   syntactically very close to record-route.  also, name 
> path is not at
> >   all descriptive, what path?
> 
> I polled the list on April 1, and received about a dozen responses
> indicating a preference for Path. Nobody responded in favor of RRR.
> 
>  
> > - this paragraph should be moved, since somebody's 
> > suggestions regarding
> >   things that are outside the scope of the i-d should not be part of
> >   the normative text:
> > 
> >   It has been suggested that the UA MAY choose to store the 
> > contents of
> >   the Path header for future use as a preloaded Route for 
> use when the
> >   UA wishes to send a SIP message that, for reasons of acquiring
> >   services in the home network, need to transit the service 
> proxies in
> >   the home network.  Such usage is explicitly outside the 
> > scope of this
> >   document.
> > 
> 
> This seems reasonable, and unless there are objections I intend to
> delete in next revision.
> 
> --
> 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 daemon@optimus.ietf.org  Thu May  9 07:52:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16228
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 07:52:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA19803
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 07:52:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18649;
	Thu, 9 May 2002 07:29:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18618
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 07:29:47 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15934
	for <sip@ietf.org>; Thu, 9 May 2002 07:29:38 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 175m4B-0000jx-00; Thu, 09 May 2002 14:26:35 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15578.23787.346977.576225@harjus.eng.song.fi>
Date: Thu, 9 May 2002 14:26:35 +0300
To: "Drage, Keith (Keith)" <drage@lucent.com>
Cc: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org,
        "'3GPP_TSG_CN_WG1'" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        bernhard.honeisen@nokia.com, "'Rohan Mahy'" <rohan@cisco.com>,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: RE: [Sip] WGLC for draft-willis-sip-path-05
In-Reply-To: <475FF955A05DD411980D00508B6D5FB004FE92C8@en0033exch001u.uk.lucent.com>
References: <475FF955A05DD411980D00508B6D5FB004FE92C8@en0033exch001u.uk.lucent.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Drage, Keith (Keith) writes:

 > I not not sure that deletion solves the problem. We still need to retain
 > text that the usage of this information from the REGISTER response in the UA
 > is outside the scope of the specification.
 > 
 > Or is that recorded somewhere else?

yes, that has already been said in section 3:

   The originating
   UA is therefore informed of the inclusion of nodes on its registered
   Path, and MAY use that information in other capacities outside the
   scope of this document.

-- 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 daemon@optimus.ietf.org  Thu May  9 10:19:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23353
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 10:19:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA29279
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 10:19:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27438;
	Thu, 9 May 2002 09:58:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27411
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 09:58:49 -0400 (EDT)
Received: from crash.dfw.dynamicsoft.com ([63.110.3.64])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21954
	for <sip@ietf.org>; Thu, 9 May 2002 09:58:39 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g49E2GV29548;
	Thu, 9 May 2002 09:02:16 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: "Chiou, Mark" <MChiou@Santera.com>
Cc: sip@ietf.org, Sridhar Kuppanna <sridhar_03@yahoo.com>
In-Reply-To: 
	<CD110021698980419241042CF576B8F2014C3033@EXCALIBUR.santera.com>
References: <CD110021698980419241042CF576B8F2014C3033@EXCALIBUR.santera.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 09 May 2002 08:58:07 -0500
Message-Id: <1020952687.1614.18.camel@dhcp152.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Question regarding draft-ietf-sip-cc-transfer-05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

On Wed, 2002-05-08 at 12:04, Chiou, Mark wrote:
> Hi Robert,
> 
> This is a question regarding Call transfer successful scenario.
> 
> In the Call transfer draft, section 4, it mentions the connection between transferor and the transferee MUST be maintained in case of un-successful cases. (i.e. No answer, busy, & etc.), such that the transferor has the ability to retreat the call back.
> 
> In section 5, it mentions "Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request." 
> 
> The questions are :
> 
> 1) neither party (transferor or the transferee) physically hits an "end" key to release the call, then the session will not be released. Is it what we want? It wastes resources.

The draft does not place a requirement for there to be a physical action
on the part of either party in order for the BYE to be sent. Is it only
the sentence above that gave you that impression or was there something
else?

It is very important that the REFER itself not tear down a dialog - that
has to happen with a BYE. The BYE can (and usually will) be sent as part
of the transfer application once the REFER association compeletes (the
REFERor sees a NOTIFY with a sufficient final response, or decides it
doesn't care anymore).

> 
> 2) each party (transferor or transferee) can send a re-INVITE request message to get the conversation back. It is different behavior than the PSTN network. (In the existing call transfer, especially PSTN network, the connection between transferor and the transferee is released.)
And this is a very good thing. If our goal is only to reproduce the
PSTN, we're wasting our time - we've already got a PSTN that does that.
We must do more.
> 
> 3) If the transferee sends a re-INVITE request message to the transferor, does it become a 3-way call? 
Not without extra mechanism.

For the scenario you are thinking about, the transferee would end up in
two distinct dialogs with thier own sessions (and would have to use
whatever interface motif it has available for multiple calls).

When the conferencing work ripens a little more, we'll see that the
REFER could be to a conference that the transferor and transferee were
already in. The conferencing mechanisms would have to recognize the
reinvite reactivated a leg in the same conference.
> 
> Here is my penny thought, Can we change the note in section 5 as" the User Agent application for the transferor SHALL automatically send a subsequent BYE request message to release the session between the transferor and the transferee"? For transferee, we might say " the User Agent application for the transferee MAY automatically send a subsequent BYE request message to release the session between the transferor and the transferee."
No - it needs to be MAY for both.
> 
> By the way, I do not have problem for a PSTN user as the transferor because the PSTN network (i.e. switch) will ensure the disconnect, which is mapped to a BYE request message for the IP network. The same behavior is used for MGCP user too. The only problem is in SIP environment (i.e. Transferor, transferee and transfer Target are SIP phones), which requires an extra step to release the session.
> 
> Regards,
> 
> Mark Chiou



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



From daemon@optimus.ietf.org  Thu May  9 11:37:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25959
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 11:37:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA04114
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 11:37:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02407;
	Thu, 9 May 2002 11:06:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02378
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 11:06:04 -0400 (EDT)
Received: from excalibur.santera.com (exchange.santera.com [4.22.157.11])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25126
	for <sip@ietf.org>; Thu, 9 May 2002 11:05:53 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 9 May 2002 10:05:22 -0500
Message-ID: <CD110021698980419241042CF576B8F2014C33C8@EXCALIBUR.santera.com>
Thread-Topic: Question regarding draft-ietf-sip-cc-transfer-05
thread-index: AcH3YZNB/HP3nl9RQFWf9ErgmHRAugACGbAA
From: "Chiou, Mark" <MChiou@Santera.com>
To: "Robert Sparks" <rsparks@dynamicsoft.com>
Cc: <sip@ietf.org>, "Sridhar Kuppanna" <sridhar_03@yahoo.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA02379
Subject: [Sip] RE: Question regarding draft-ietf-sip-cc-transfer-05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi Robert,

Thanks for clarification. I agree the REFER should not tear down the session between the transferor and the transferee. But the Call Transfer application SHOULD tear down the session between the transferor and the transferee for successful case.

Thanks again,

Mark

-----Original Message-----
From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
Sent: Thursday, May 09, 2002 8:58 AM
To: Chiou, Mark
Cc: sip@ietf.org; Sridhar Kuppanna
Subject: Re: Question regarding draft-ietf-sip-cc-transfer-05


On Wed, 2002-05-08 at 12:04, Chiou, Mark wrote:
> Hi Robert,
> 
> This is a question regarding Call transfer successful scenario.
> 
> In the Call transfer draft, section 4, it mentions the connection between transferor and the transferee MUST be maintained in case of un-successful cases. (i.e. No answer, busy, & etc.), such that the transferor has the ability to retreat the call back.
> 
> In section 5, it mentions "Note that a successful REFER transaction does not terminate the session between the Transferor and the Transferee. If those parties wish to terminate their session, they must do so with a subsequent BYE request." 
> 
> The questions are :
> 
> 1) neither party (transferor or the transferee) physically hits an "end" key to release the call, then the session will not be released. Is it what we want? It wastes resources.

The draft does not place a requirement for there to be a physical action
on the part of either party in order for the BYE to be sent. Is it only
the sentence above that gave you that impression or was there something
else?

It is very important that the REFER itself not tear down a dialog - that
has to happen with a BYE. The BYE can (and usually will) be sent as part
of the transfer application once the REFER association compeletes (the
REFERor sees a NOTIFY with a sufficient final response, or decides it
doesn't care anymore).

> 
> 2) each party (transferor or transferee) can send a re-INVITE request message to get the conversation back. It is different behavior than the PSTN network. (In the existing call transfer, especially PSTN network, the connection between transferor and the transferee is released.)
And this is a very good thing. If our goal is only to reproduce the
PSTN, we're wasting our time - we've already got a PSTN that does that.
We must do more.
> 
> 3) If the transferee sends a re-INVITE request message to the transferor, does it become a 3-way call? 
Not without extra mechanism.

For the scenario you are thinking about, the transferee would end up in
two distinct dialogs with thier own sessions (and would have to use
whatever interface motif it has available for multiple calls).

When the conferencing work ripens a little more, we'll see that the
REFER could be to a conference that the transferor and transferee were
already in. The conferencing mechanisms would have to recognize the
reinvite reactivated a leg in the same conference.
> 
> Here is my penny thought, Can we change the note in section 5 as" the User Agent application for the transferor SHALL automatically send a subsequent BYE request message to release the session between the transferor and the transferee"? For transferee, we might say " the User Agent application for the transferee MAY automatically send a subsequent BYE request message to release the session between the transferor and the transferee."
No - it needs to be MAY for both.
> 
> By the way, I do not have problem for a PSTN user as the transferor because the PSTN network (i.e. switch) will ensure the disconnect, which is mapped to a BYE request message for the IP network. The same behavior is used for MGCP user too. The only problem is in SIP environment (i.e. Transferor, transferee and transfer Target are SIP phones), which requires an extra step to release the session.
> 
> Regards,
> 
> Mark Chiou



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



From daemon@optimus.ietf.org  Thu May  9 13:15:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01115
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 13:15:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA10865
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:15:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08085;
	Thu, 9 May 2002 12:42:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08033
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 12:42:36 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28898
	for <sip@ietf.org>; Thu, 9 May 2002 12:42:27 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49GfvY15444
	for <sip@ietf.org>; Thu, 9 May 2002 18:41:57 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49GfD300975
	for <sip@ietf.org>; Thu, 9 May 2002 17:41:13 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KHH1Q1MK>; Thu, 9 May 2002 17:42:27 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F71F7@zwcwd00r.europe.nortel.com>
From: "Mark Watson"<mwatson@nortelnetworks.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Thu, 9 May 2002 17:42:20 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F778.7CE2787C"
Subject: [Sip] Network Asserted Identity
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1F778.7CE2787C
Content-Type: text/plain;
	charset="iso-8859-1"

All,

Revision of the requirements draft coming soon.

In the meantime there are two issues which we did not completely bottom out
at the meeting. It would be good if we could conclude on these asap,
particularly as 3GPP has a meeting next week at which I hope they will
incorporate this new IETF work into their spec.

> 1) Name of the identity header
> 
The following have been suggested:
	Network-Asserted-ID:
	Authenticated-Identity:
	NA-From:
	Network-From:
	Asserted-Identity:
	others ?

Comments on these are:
	Network-Asserted-ID has an acronym clash with Network Access
Identity from AAA.
	Authenticated-Identity is not appropriate use of the term
'Authenticated' as the identity is not actually accompanied by a signature
	Asserted-Identity: what is an 'unasserted' identity ?

Suggestions & votes please! (If you vote in order of preference I can do a
Single Transferable Vote election).

> 2) UA 'hint' to authenticating proxy 
> 
One of the 3GPP requirements was for the UA to be able to supply a 'hint' to
the Authenticating Proxy in the case that the UA has several identities.
i.e. the UA could choose from several possible NAIs. Cullen's draft proposes
that the same header be used for this purpose. If there are objections to
this please speak now!! The alternative would presumably be a P-Header for
this.

> Regards...Mark
> 
> 
> 
> 
> 
> 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Network Asserted Identity</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">All,</FONT>
<BR>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">Revision of the =
requirements draft coming soon.</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">In the meantime =
there are two issues which we did not completely bottom out at the =
meeting. It would be good if we could conclude on these asap, =
particularly as 3GPP has a meeting next week at which I hope they will =
incorporate this new IETF work into their spec.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">1) Name of the =
identity header</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">The following have =
been suggested:</FONT>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Network-Asserted-ID:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Authenticated-Identity:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">NA-From:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Network-From:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Asserted-Identity:</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">others ?</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">Comments on these =
are:</FONT>
<UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Network-Asserted-ID has an acronym clash with Network =
Access Identity from AAA.</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Authenticated-Identity is not appropriate use of the =
term 'Authenticated' as the identity is not actually accompanied by a =
signature</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">Asserted-Identity: =
what is an 'unasserted' identity ?</FONT>
</P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">Suggestions &amp; =
votes please! (If you vote in order of preference I can do a Single =
Transferable Vote election).</FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">2) UA 'hint' to =
authenticating proxy </FONT>
</P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 FACE=3D"Verdana">One of the 3GPP =
requirements was for the UA to be able to supply a 'hint' to the =
Authenticating Proxy in the case that the UA has several identities. =
i.e. the UA could choose from several possible NAIs. Cullen's draft =
proposes that the same header be used for this purpose. If there are =
objections to this please speak now!! The alternative would presumably =
be a P-Header for this.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D1 =
FACE=3D"Verdana">Regards...Mark</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1F778.7CE2787C--

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



From daemon@optimus.ietf.org  Thu May  9 13:26:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01545
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 13:26:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA11252
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:26:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10240;
	Thu, 9 May 2002 13:05:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10211
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 13:05:09 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00402
	for <sip@ietf.org>; Thu, 9 May 2002 13:05:00 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g49H4c5M016147
	for <sip@ietf.org>; Thu, 9 May 2002 10:04:38 -0700 (PDT)
Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AAD39228;
	Thu, 9 May 2002 10:04:38 -0700 (PDT)
Date: Thu, 9 May 2002 10:01:18 -0700 (Pacific Daylight Time)
From: Rohan Mahy <rohan@cisco.com>
To: sip@ietf.org
Message-ID: <Pine.WNT.4.44.0205090949110.-282323@chorizo.rapidconvergence.com>
X-X-Sender: rmahy@imop.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Sip] Proposal to move forward on privacy and network identity
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi Folks,

We reached a proto-consensus at the interim meeting.  I wanted to poll the
list for consensus on this proposal.

Proposal:
Adopt draft-watson-sipping-nai-reqs as a WG item in SIPPING (short-term
requirements for network asserted ID)  (I sent a separate mail to SIPPING
on this).

Adopt draft-peterson-sip-privacy-longterm as a WG item in SIP for generic
privacy.

Replace draft-ietf-sip-privacy-04.txt with
draft-jennings-sipping-nai-00.txt as a reduced-scope solution for network
asserted ID in trusted networks.

Adopt draft-peterson-sip-identity as a WG item in SIP for a generic
solution to 3rd-party cryptographic assertions of identity.

Jon Peterson, Mark Watson, and Cullen Jennings work to document a
mechanism to provide for a gateway between the "trusted network" and
"cryptographically signed" models of network asserted identity.  Both
mechanisms would use a "Network-Asserted-ID" header.

Comments?

thanks,
-rohan




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



From daemon@optimus.ietf.org  Thu May  9 13:58:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02639
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 13:58:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA13448
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:58:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12541;
	Thu, 9 May 2002 13:40:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12510
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 13:40:29 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02146
	for <sip@ietf.org>; Thu, 9 May 2002 13:40:17 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 175rtv-0000n3-00; Thu, 09 May 2002 20:40:23 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15578.46214.978436.188750@harjus.eng.song.fi>
Date: Thu, 9 May 2002 20:40:22 +0300
To: "Mark Watson"<mwatson@nortelnetworks.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: [Sip] Network Asserted Identity
In-Reply-To: <A3C2399B2FACD411A54200508BE39C74054F71F7@zwcwd00r.europe.nortel.com>
References: <A3C2399B2FACD411A54200508BE39C74054F71F7@zwcwd00r.europe.nortel.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Mark Watson writes:

 > One of the 3GPP requirements was for the UA to be able to supply a 'hint' to
 > the Authenticating Proxy in the case that the UA has several identities.
 > i.e. the UA could choose from several possible NAIs. Cullen's draft proposes
 > that the same header be used for this purpose. If there are objections to
 > this please speak now!! The alternative would presumably be a P-Header for
 > this.

the same header is fine with me, but i made several comments on the
procedures at the proxy regarding the hint and i only got feedback
privately.  my main point was that if the user has several valid from
identities, it MUST give a hint, because the proxy has no way to know
which one it should pick.

-- 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 daemon@optimus.ietf.org  Thu May  9 13:59:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02698
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 13:59:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA13472
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 13:59:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11856;
	Thu, 9 May 2002 13:31:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11825
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 13:31:48 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01697
	for <sip@ietf.org>; Thu, 9 May 2002 13:31:39 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA28332;
	Thu, 9 May 2002 13:31:09 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22040;
	Thu, 9 May 2002 13:31:10 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <J79SVC02>; Thu, 9 May 2002 13:31:08 -0400
Message-ID: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'sip@ietf.org'"
	 <sip@ietf.org>
Subject: RE: [Sip] Network Asserted Identity
Date: Thu, 9 May 2002 13:31:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

I like Network Asserted ID best
NA From is okay, but if we DO decide to allow an NAI on a Reply To, for
example, 
we would need an NA-Reply-To, which has it's plusses and minuses
Network-From has the same problem Asserted-Indentity is okay, 
but not as nice a Network Asserted ID

On the hint, I don't understand why From isn't the hint.  Could you explain?
Assuming there is a good reason, I'd use the same header name.  
That kind of makes Asserted-Identity a better choice.

Brian
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Thursday, May 09, 2002 12:42 PM
To: 'sip@ietf.org'
Subject: [Sip] Network Asserted Identity


All, 

Revision of the requirements draft coming soon. 
In the meantime there are two issues which we did not completely bottom out
at the meeting. It would be good if we could conclude on these asap,
particularly as 3GPP has a meeting next week at which I hope they will
incorporate this new IETF work into their spec.
1) Name of the identity header 
The following have been suggested: 
Network-Asserted-ID: 
Authenticated-Identity: 
NA-From: 
Network-From: 
Asserted-Identity: 
others ? 
Comments on these are: 
Network-Asserted-ID has an acronym clash with Network Access Identity from
AAA. 
Authenticated-Identity is not appropriate use of the term 'Authenticated' as
the identity is not actually accompanied by a signature
Asserted-Identity: what is an 'unasserted' identity ? 
Suggestions & votes please! (If you vote in order of preference I can do a
Single Transferable Vote election). 
2) UA 'hint' to authenticating proxy 
One of the 3GPP requirements was for the UA to be able to supply a 'hint' to
the Authenticating Proxy in the case that the UA has several identities.
i.e. the UA could choose from several possible NAIs. Cullen's draft proposes
that the same header be used for this purpose. If there are objections to
this please speak now!! The alternative would presumably be a P-Header for
this.
Regards...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 daemon@optimus.ietf.org  Thu May  9 14:28:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04120
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 14:28:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA15789
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 14:29:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14393;
	Thu, 9 May 2002 14:07:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA14368
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 14:07:16 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03030
	for <sip@ietf.org>; Thu, 9 May 2002 14:07:06 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 175sJt-0000nW-00; Thu, 09 May 2002 21:07:13 +0300
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'sip@ietf.org'"
	 <sip@ietf.org>
Subject: RE: [Sip] Network Asserted Identity
In-Reply-To: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com>
References: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Message-Id: <E175sJt-0000nW-00@lohi.eng.song.fi>
Date: Thu, 09 May 2002 21:07:13 +0300
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Rosen, Brian writes:

 > On the hint, I don't understand why From isn't the hint.  Could you explain?
 > Assuming there is a good reason, I'd use the same header name.  
 > That kind of makes Asserted-Identity a better choice.

if the user wants to be anonymous, then from can't contain a hint.  if
from is not anonymous, then from can and for backwards compatibility
reasons SHOULD be considered a hint in the absence of a nai header.

-- 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 daemon@optimus.ietf.org  Thu May  9 15:00:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05114
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 15:00:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA17803
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 15:00:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16647;
	Thu, 9 May 2002 14:41:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16616
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 14:41:04 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04652
	for <sip@ietf.org>; Thu, 9 May 2002 14:40:55 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g49Ied504085;
	Thu, 9 May 2002 13:40:39 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXXPD91>; Thu, 9 May 2002 13:40:59 -0500
Message-ID: <1B54FA3A2709D51195C800508BF9386A03DE3ABE@zrc2c000.us.nortel.com>
From: "Mary Barnes"<mbarnes@nortelnetworks.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "Mark Watson"<mwatson@nortelnetworks.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] Network Asserted Identity
Date: Thu, 9 May 2002 13:40:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F789.0FCAE560"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1F789.0FCAE560
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

The only concern I have with NAI is purely wrt potential confusion with the
"Network Access Identifier" as defined in RFC 2486.  Back in the days that I
was working in the mobile IP and AAA space, this was a common term (per RFC
2794).  Maybe it's just me, but before I read the draft, I had assumed that
it was discussing the use of the RFC 2568 NAI in the SIP world, thus my
suggestion would be AI (Asserted-Identity).

Mary. 

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Thursday, May 09, 2002 12:31 PM
To: Watson, Mark [MDN05:EP10:EXCH]; 'sip@ietf.org'
Subject: RE: [Sip] Network Asserted Identity


I like Network Asserted ID best
NA From is okay, but if we DO decide to allow an NAI on a Reply To, for
example, 
we would need an NA-Reply-To, which has it's plusses and minuses
Network-From has the same problem Asserted-Indentity is okay, 
but not as nice a Network Asserted ID

On the hint, I don't understand why From isn't the hint.  Could you explain?
Assuming there is a good reason, I'd use the same header name.  
That kind of makes Asserted-Identity a better choice.

Brian
-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Thursday, May 09, 2002 12:42 PM
To: 'sip@ietf.org'
Subject: [Sip] Network Asserted Identity


All, 

Revision of the requirements draft coming soon. 
In the meantime there are two issues which we did not completely bottom out
at the meeting. It would be good if we could conclude on these asap,
particularly as 3GPP has a meeting next week at which I hope they will
incorporate this new IETF work into their spec.
1) Name of the identity header 
The following have been suggested: 
Network-Asserted-ID: 
Authenticated-Identity: 
NA-From: 
Network-From: 
Asserted-Identity: 
others ? 
Comments on these are: 
Network-Asserted-ID has an acronym clash with Network Access Identity from
AAA. 
Authenticated-Identity is not appropriate use of the term 'Authenticated' as
the identity is not actually accompanied by a signature
Asserted-Identity: what is an 'unasserted' identity ? 
Suggestions & votes please! (If you vote in order of preference I can do a
Single Transferable Vote election). 
2) UA 'hint' to authenticating proxy 
One of the 3GPP requirements was for the UA to be able to supply a 'hint' to
the Authenticating Proxy in the case that the UA has several identities.
i.e. the UA could choose from several possible NAIs. Cullen's draft proposes
that the same header be used for this purpose. If there are objections to
this please speak now!! The alternative would presumably be a P-Header for
this.
Regards...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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Sip] Network Asserted Identity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi all,</FONT>
</P>

<P><FONT SIZE=3D2>The only concern I have with NAI is purely wrt =
potential confusion with the &quot;Network Access Identifier&quot; as =
defined in RFC 2486.&nbsp; Back in the days that I was working in the =
mobile IP and AAA space, this was a common term (per RFC 2794).&nbsp; =
Maybe it's just me, but before I read the draft, I had assumed that it =
was discussing the use of the RFC 2568 NAI in the SIP world, thus my =
suggestion would be AI (Asserted-Identity).</FONT></P>

<P><FONT SIZE=3D2>Mary. </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Rosen, Brian [<A =
HREF=3D"mailto:Brian.Rosen@marconi.com">mailto:Brian.Rosen@marconi.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 09, 2002 12:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Watson, Mark [MDN05:EP10:EXCH]; =
'sip@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [Sip] Network Asserted Identity</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I like Network Asserted ID best</FONT>
<BR><FONT SIZE=3D2>NA From is okay, but if we DO decide to allow an NAI =
on a Reply To, for</FONT>
<BR><FONT SIZE=3D2>example, </FONT>
<BR><FONT SIZE=3D2>we would need an NA-Reply-To, which has it's plusses =
and minuses</FONT>
<BR><FONT SIZE=3D2>Network-From has the same problem Asserted-Indentity =
is okay, </FONT>
<BR><FONT SIZE=3D2>but not as nice a Network Asserted ID</FONT>
</P>

<P><FONT SIZE=3D2>On the hint, I don't understand why From isn't the =
hint.&nbsp; Could you explain?</FONT>
<BR><FONT SIZE=3D2>Assuming there is a good reason, I'd use the same =
header name.&nbsp; </FONT>
<BR><FONT SIZE=3D2>That kind of makes Asserted-Identity a better =
choice.</FONT>
</P>

<P><FONT SIZE=3D2>Brian</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Mark Watson [<A =
HREF=3D"mailto:mwatson@nortelnetworks.com">mailto:mwatson@nortelnetworks=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, May 09, 2002 12:42 PM</FONT>
<BR><FONT SIZE=3D2>To: 'sip@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: [Sip] Network Asserted Identity</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>Revision of the requirements draft coming soon. =
</FONT>
<BR><FONT SIZE=3D2>In the meantime there are two issues which we did =
not completely bottom out</FONT>
<BR><FONT SIZE=3D2>at the meeting. It would be good if we could =
conclude on these asap,</FONT>
<BR><FONT SIZE=3D2>particularly as 3GPP has a meeting next week at =
which I hope they will</FONT>
<BR><FONT SIZE=3D2>incorporate this new IETF work into their =
spec.</FONT>
<BR><FONT SIZE=3D2>1) Name of the identity header </FONT>
<BR><FONT SIZE=3D2>The following have been suggested: </FONT>
<BR><FONT SIZE=3D2>Network-Asserted-ID: </FONT>
<BR><FONT SIZE=3D2>Authenticated-Identity: </FONT>
<BR><FONT SIZE=3D2>NA-From: </FONT>
<BR><FONT SIZE=3D2>Network-From: </FONT>
<BR><FONT SIZE=3D2>Asserted-Identity: </FONT>
<BR><FONT SIZE=3D2>others ? </FONT>
<BR><FONT SIZE=3D2>Comments on these are: </FONT>
<BR><FONT SIZE=3D2>Network-Asserted-ID has an acronym clash with =
Network Access Identity from</FONT>
<BR><FONT SIZE=3D2>AAA. </FONT>
<BR><FONT SIZE=3D2>Authenticated-Identity is not appropriate use of the =
term 'Authenticated' as</FONT>
<BR><FONT SIZE=3D2>the identity is not actually accompanied by a =
signature</FONT>
<BR><FONT SIZE=3D2>Asserted-Identity: what is an 'unasserted' identity =
? </FONT>
<BR><FONT SIZE=3D2>Suggestions &amp; votes please! (If you vote in =
order of preference I can do a</FONT>
<BR><FONT SIZE=3D2>Single Transferable Vote election). </FONT>
<BR><FONT SIZE=3D2>2) UA 'hint' to authenticating proxy </FONT>
<BR><FONT SIZE=3D2>One of the 3GPP requirements was for the UA to be =
able to supply a 'hint' to</FONT>
<BR><FONT SIZE=3D2>the Authenticating Proxy in the case that the UA has =
several identities.</FONT>
<BR><FONT SIZE=3D2>i.e. the UA could choose from several possible NAIs. =
Cullen's draft proposes</FONT>
<BR><FONT SIZE=3D2>that the same header be used for this purpose. If =
there are objections to</FONT>
<BR><FONT SIZE=3D2>this please speak now!! The alternative would =
presumably be a P-Header for</FONT>
<BR><FONT SIZE=3D2>this.</FONT>
<BR><FONT SIZE=3D2>Regards...Mark </FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>This list is for NEW development of the core SIP =
Protocol</FONT>
<BR><FONT SIZE=3D2>Use sip-implementors@cs.columbia.edu for questions =
on current sip</FONT>
<BR><FONT SIZE=3D2>Use sipping@ietf.org for new developments on the =
application of sip</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F789.0FCAE560--

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



From daemon@optimus.ietf.org  Thu May  9 15:31:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06292
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 15:31:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA19464
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 15:31:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18438;
	Thu, 9 May 2002 15:09:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18409
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 15:09:53 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05480
	for <sip@ietf.org>; Thu, 9 May 2002 15:09:43 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g49J99d06493;
	Thu, 9 May 2002 14:09:09 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'Mark Watson'" <mwatson@nortelnetworks.com>, <sip@ietf.org>
Subject: RE: [Sip] Network Asserted Identity
Date: Thu, 9 May 2002 14:08:53 -0500
Message-ID: <007f01c1f78c$f63bf090$4a010114@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <313680C9A886D511A06000204840E1CF030B52CC@whq-msgusr-02.pit.comms.marconi.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> On the hint, I don't understand why From isn't the hint.  
> Could you explain? Assuming there is a good reason, I'd use 
> the same header name.  
> That kind of makes Asserted-Identity a better choice.

From: isn't the hint because there may need to be network assertion of
identity even when there is a privacy request from the user. Unless we
want proxies munging From: (insert my many arguments here) then the hint
needs to be in another place that CAN be proxy-munged. This leaves the
UA responsible for its From: field (sets "anonymous" or equiavelent if
privacy required) which is cleaner and has better
backward-compatibility.

I like "Asserted-Identity", as future techniques lets us say WHO
asserted the identity, and it might be "the network", the user, or a
third-party authentication service.

--
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 daemon@optimus.ietf.org  Thu May  9 19:30:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13875
	for <sip-archive@odin.ietf.org>; Thu, 9 May 2002 19:30:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA01789
	for sip-archive@odin.ietf.org; Thu, 9 May 2002 19:30:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00133;
	Thu, 9 May 2002 18:55:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA00107
	for <sip@optimus.ietf.org>; Thu, 9 May 2002 18:55:11 -0400 (EDT)
Received: from mail1.telefonica.com.ar ([168.226.49.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12705
	for <sip@ietf.org>; Thu, 9 May 2002 18:55:01 -0400 (EDT)
Received: by MAIL1 with Internet Mail Service (5.5.2653.19)
	id <KR4X6G9M>; Thu, 9 May 2002 19:55:03 -0300
Message-ID: <19364262E259D51198BA0008C7E6528E05199474@MSTELEFONICA8>
From: De Leo Walter <deleow@telefonica.com.ar>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Thu, 9 May 2002 19:54:45 -0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Sip] minor nit in bis-09.
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Surely was already noticed but just in case:

In page 145 second paragraph it says ....This is only to provide backwards
compatibility with RFC2543 compliant implementations that do not support
UDP.  It should say TCP.

Sorry, i dont have the pdf version at hand so i cannot provide line numbers.

regards

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



From daemon@optimus.ietf.org  Fri May 10 01:24:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28514
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 01:24:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA23981
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 01:24:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14679;
	Fri, 10 May 2002 00:48:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14643
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 00:48:14 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27691
	for <sip@ietf.org>; Fri, 10 May 2002 00:48:04 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4A4lhHT028518;
	Thu, 9 May 2002 21:47:43 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACW57133;
	Thu, 9 May 2002 21:47:55 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <sip@ietf.org>, "Dean Willis" <dean.willis@softarmor.com>
Cc: "Fluffy" <fluffy@cisco.com>, "Jon Peterson" <jon.peterson@neustar.biz>,
        "Mark Watson" <mwatson@nortelnetworks.com>
Date: Thu, 9 May 2002 21:48:00 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCOEAKCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <15578.46214.978436.188750@harjus.eng.song.fi>
Content-Transfer-Encoding: 7bit
Subject: [Sip] NAI - Jon/Mark/Cullen Proposal
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I promised Dean to capture one bit of the minutes - this is it :-)

There was considerable discussion about privacy and identity stuff at the
interim meeting. At the time we were using the terms short term and long
term to describe the proposals.  A better description to separate the two
would be cryptographic and non-cryptographic approach.

The proposal from Jon, Mark, and I is to go forward by looking at a solution
that is something along the lines of:

1) Have a header called something like Asserted-Identity
2) In the non cryptographic solution, this header could appear in the header
portion of the message
3) In the cryptographic solution, this header could be used in signed and
encrypted sipfrags in the body of the message

We need to carefully think about the implications of both the cryptographic
and non-cryptographic solution existing and what would happen as messages
were passed from a network element using one type to a network element using
the other type.

Cullen



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



From daemon@optimus.ietf.org  Fri May 10 02:57:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09118
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 02:57:06 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA28249
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 02:57:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27602;
	Fri, 10 May 2002 02:35:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27573
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 02:35:03 -0400 (EDT)
Received: from blaze.hcltech.com ([203.199.199.225])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08839
	for <sip@ietf.org>; Fri, 10 May 2002 02:34:54 -0400 (EDT)
Received: from suryapc (surya-pc.hclt-guindy.co.in [192.168.201.166])
	by blaze.hcltech.com (8.9.3/8.9.3) with SMTP id MAA30147;
	Fri, 10 May 2002 12:07:23 +0530
Message-ID: <00bb01c1f7e8$cb8244b0$a6c9a8c0@hcltguindy.co.in>
From: "Surya Kumar IVG" <surya@netlab.hcltech.com>
To: "De Leo Walter" <deleow@telefonica.com.ar>, <sip@ietf.org>
References: <19364262E259D51198BA0008C7E6528E05199474@MSTELEFONICA8>
Subject: Re: [Sip] minor nit in bis-09.
Date: Fri, 10 May 2002 11:36:16 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Yes, I think that is true,as earlier drafts has taken an inclination towards
supporting UDP and later versions moved towards TCP

----- Original Message -----
From: "De Leo Walter" <deleow@TELEFONICA.COM.AR>
To: <sip@ietf.org>
Sent: Friday, May 10, 2002 4:24 AM
Subject: [Sip] minor nit in bis-09.


> Surely was already noticed but just in case:
>
> In page 145 second paragraph it says ....This is only to provide backwards
> compatibility with RFC2543 compliant implementations that do not support
> UDP.  It should say TCP.
>
> Sorry, i dont have the pdf version at hand so i cannot provide line
numbers.
>
> regards
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 03:13:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09579
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 03:13:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA29314
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 03:13:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27807;
	Fri, 10 May 2002 02:41:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA27778
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 02:41:31 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08888
	for <sip@ietf.org>; Fri, 10 May 2002 02:41:22 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4A6fU0E021464
	for <sip@ietf.org>; Fri, 10 May 2002 08:41:30 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4A6fU9q025486
	for <sip@ietf.org>; Fri, 10 May 2002 09:41:30 +0300 (EET DST)
Message-ID: <3CDB6B99.AE255408@lmf.ericsson.se>
Date: Fri, 10 May 2002 09:41:30 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Header comparision
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Hi,

I have a small clarification question on To- and From header
comparision.

Chapter 8.2.6.2 says:

"The From field of the response MUST equal the From header field of
the request."

Later in the chapter it explains the use of tags.

However, there is nothing said (not in the URI comparision chapter
either) about the "<" and ">" characters, so my question is:

If the UAC doesn't include "<" and ">" in the request, and the UAS DOES
include them in the response, is it a protocol error?

example:

Request:

To: el.sipo@sipworld.sip

Response:

To: <el.sipo@sipworld.sip>


Regards,

Christer Holmberg
Ericsson Finland




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



From daemon@optimus.ietf.org  Fri May 10 04:01:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10133
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 04:01:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA01848
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 04:01:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00660;
	Fri, 10 May 2002 03:39:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00629
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 03:39:11 -0400 (EDT)
Received: from nghmail ([63.104.239.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09912
	for <sip@ietf.org>; Fri, 10 May 2002 03:39:02 -0400 (EDT)
Received: (qmail 3426 invoked from network); 10 May 2002 08:39:46 -0000
Received: from unknown (HELO MC24Madhu) (61.11.57.39)
  by nghmail with SMTP; 10 May 2002 08:39:46 -0000
Message-ID: <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net>
From: "Madhusudhan" <madhusudhan@knowsys.net>
To: <christer.holmberg@lmf.ericsson.se>, <sip@ietf.org>
References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net>
Subject: Re: [Sip] Header comparision
Date: Fri, 10 May 2002 13:07:56 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi

Section 20 of bis09 mentions

  "The Contact, From, and To header fields contain a URI. If the URI
   contains a comma, question mark or semicolon, the URI MUST be
   enclosed in angle brackets (< and >). Any URI parameters are
   contained within these brackets. If the URI is not enclosed in angle
   brackets, any semicolon-delimited parameters are header-parameters,
   not URI parameters"

 From the above comments, I think it is evident that the two addresses are
different.

correct me if I am wrong!!!

Regards

Madhusudhan

>
> ----- Original Message -----
> From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> To: <sip@ietf.org>
> Sent: Friday, May 10, 2002 12:11 PM
> Subject: [Sip] Header comparision
>
>
> >
> > Hi,
> >
> > I have a small clarification question on To- and From header
> > comparision.
> >
> > Chapter 8.2.6.2 says:
> >
> > "The From field of the response MUST equal the From header field of
> > the request."
> >
> > Later in the chapter it explains the use of tags.
> >
> > However, there is nothing said (not in the URI comparision chapter
> > either) about the "<" and ">" characters, so my question is:
> >
> > If the UAC doesn't include "<" and ">" in the request, and the UAS DOES
> > include them in the response, is it a protocol error?
> >
> > example:
> >
> > Request:
> >
> > To: el.sipo@sipworld.sip
> >
> > Response:
> >
> > To: <el.sipo@sipworld.sip>
> >
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 04:18:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10461
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 04:18:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA02313
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 04:18:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01968;
	Fri, 10 May 2002 04:05:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01937
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 04:05:57 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10226
	for <sip@ietf.org>; Fri, 10 May 2002 04:05:47 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4A85ss7020433;
	Fri, 10 May 2002 10:05:54 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4A85s9q029502;
	Fri, 10 May 2002 11:05:54 +0300 (EET DST)
Message-ID: <3CDB7F62.7DE4B42C@lmf.ericsson.se>
Date: Fri, 10 May 2002 11:05:54 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Madhusudhan <madhusudhan@knowsys.net>
CC: sip@ietf.org
Subject: Re: [Sip] Header comparision
References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Hi Madhusudhan,

Thanks for your comments!

However, I think we are talking about two separate issues.

Yes, in some cases (as mentioned) the URI MUST be enclosed in angle brackets,
but that does NOT mean you aren't allowed to enclose the URI in angle brackets
ALSO in other cases. For example:

To: <sip:el.sipo@sipworld.com>

...is allowed from a SIP syntax point of view.

However, my question was related to the COMPARISION of headers.

Regards,

Christer Holmberg
Ericsson Finland


Madhusudhan wrote:

> Hi
>
> Section 20 of bis09 mentions
>
>   "The Contact, From, and To header fields contain a URI. If the URI
>    contains a comma, question mark or semicolon, the URI MUST be
>    enclosed in angle brackets (< and >). Any URI parameters are
>    contained within these brackets. If the URI is not enclosed in angle
>    brackets, any semicolon-delimited parameters are header-parameters,
>    not URI parameters"
>
>  From the above comments, I think it is evident that the two addresses are
> different.
>
> correct me if I am wrong!!!
>
> Regards
>
> Madhusudhan
>
> >
> > ----- Original Message -----
> > From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> > To: <sip@ietf.org>
> > Sent: Friday, May 10, 2002 12:11 PM
> > Subject: [Sip] Header comparision
> >
> >
> > >
> > > Hi,
> > >
> > > I have a small clarification question on To- and From header
> > > comparision.
> > >
> > > Chapter 8.2.6.2 says:
> > >
> > > "The From field of the response MUST equal the From header field of
> > > the request."
> > >
> > > Later in the chapter it explains the use of tags.
> > >
> > > However, there is nothing said (not in the URI comparision chapter
> > > either) about the "<" and ">" characters, so my question is:
> > >
> > > If the UAC doesn't include "<" and ">" in the request, and the UAS DOES
> > > include them in the response, is it a protocol error?
> > >
> > > example:
> > >
> > > Request:
> > >
> > > To: el.sipo@sipworld.sip
> > >
> > > Response:
> > >
> > > To: <el.sipo@sipworld.sip>
> > >
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 04:20:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10533
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 04:20:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA02344
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 04:20:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01086;
	Fri, 10 May 2002 03:53:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01057
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 03:53:30 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10059
	for <sip@ietf.org>; Fri, 10 May 2002 03:53:21 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.172])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4A7rqYH002776;
	Fri, 10 May 2002 03:53:53 -0400 (EDT)
Message-ID: <3CDB7C37.72E1DB63@dynamicsoft.com>
Date: Fri, 10 May 2002 03:52:23 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Surya Kumar IVG <surya@netlab.hcltech.com>
CC: De Leo Walter <deleow@telefonica.com.ar>, sip@ietf.org
Subject: Re: [Sip] minor nit in bis-09.
References: <00bb01c1f7e8$cb8244b0$a6c9a8c0@hcltguindy.co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Yes, this particular bug has been reported almost half a dozen times
now...

Thanks!

-Jonathan R.

Surya Kumar IVG wrote:
> 
> Yes, I think that is true,as earlier drafts has taken an inclination
> towards
> supporting UDP and later versions moved towards TCP
> 
> ----- Original Message -----
> From: "De Leo Walter" <deleow@TELEFONICA.COM.AR>
> To: <sip@ietf.org>
> Sent: Friday, May 10, 2002 4:24 AM
> Subject: [Sip] minor nit in bis-09.
> 
> > Surely was already noticed but just in case:
> >
> > In page 145 second paragraph it says ....This is only to provide
> backwards
> > compatibility with RFC2543 compliant implementations that do not
> support
> > UDP.  It should say TCP.
> >
> > Sorry, i dont have the pdf version at hand so i cannot provide line
> numbers.
> >
> > regards
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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

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

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



From daemon@optimus.ietf.org  Fri May 10 05:34:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11297
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 05:34:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA05698
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 05:34:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03665;
	Fri, 10 May 2002 04:52:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA03633
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 04:51:58 -0400 (EDT)
Received: from nghmail ([63.104.239.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10911
	for <sip@ietf.org>; Fri, 10 May 2002 04:51:49 -0400 (EDT)
Received: (qmail 16585 invoked from network); 10 May 2002 09:52:30 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.39)
  by nghmail with SMTP; 10 May 2002 09:52:30 -0000
Message-ID: <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net>
From: "vishal" <vishal@knowsys.net>
To: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>,
        "Madhusudhan" <madhusudhan@knowsys.net>
Cc: <sip@ietf.org>
References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se>
Subject: Re: [Sip] Header comparision
Date: Fri, 10 May 2002 14:21:53 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi christer,
    From,To,Call-Id ,Cseq fields of sip response MUST exactly match
corresponding request.If it does not match exactly ,then it should be
protocol error .

Reason:
   you dont require addition checking while copying these fields .

case you described ,
To: el.sipo@sipworld.sip and
To: <el.sipo@sipworld.sip>  are equivalent ,not equal.

please refer to sip bis 09  section 8.2.6.2 below

"8.2.6.2 Headers and Tags

   The From field of the response MUST equal the From header field of
   the request. The Call-ID header field of the response MUST equal the
   Call-ID header field of the request. The CSeq header field of the
   response MUST equal the CSeq field of the request. The Via header
   field values in the response MUST equal the Via header field values
   in the request and MUST maintain the same ordering.

   If a request contained a To tag in the request, the To header field
   in the response MUST equal that of the request. However, if the To
   header field in the request did not contain a tag, the URI in the To
   header field in the response MUST equal the URI in the To header
   field; additionally, the UAS MUST add a tag to the To header field in
   the response (with the exception of the 100 (Trying) response, in
   which a tag MAY be present)"


regards, vishal




----- Original Message -----
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
To: Madhusudhan <madhusudhan@knowsys.net>
Cc: <sip@ietf.org>
Sent: Friday, May 10, 2002 1:35 PM
Subject: Re: [Sip] Header comparision


>
> Hi Madhusudhan,
>
> Thanks for your comments!
>
> However, I think we are talking about two separate issues.
>
> Yes, in some cases (as mentioned) the URI MUST be enclosed in angle
brackets,
> but that does NOT mean you aren't allowed to enclose the URI in angle
brackets
> ALSO in other cases. For example:
>
> To: <sip:el.sipo@sipworld.com>
>
> ...is allowed from a SIP syntax point of view.
>
> However, my question was related to the COMPARISION of headers.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
> Madhusudhan wrote:
>
> > Hi
> >
> > Section 20 of bis09 mentions
> >
> >   "The Contact, From, and To header fields contain a URI. If the URI
> >    contains a comma, question mark or semicolon, the URI MUST be
> >    enclosed in angle brackets (< and >). Any URI parameters are
> >    contained within these brackets. If the URI is not enclosed in angle
> >    brackets, any semicolon-delimited parameters are header-parameters,
> >    not URI parameters"
> >
> >  From the above comments, I think it is evident that the two addresses
are
> > different.
> >
> > correct me if I am wrong!!!
> >
> > Regards
> >
> > Madhusudhan
> >
> > >
> > > ----- Original Message -----
> > > From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> > > To: <sip@ietf.org>
> > > Sent: Friday, May 10, 2002 12:11 PM
> > > Subject: [Sip] Header comparision
> > >
> > >
> > > >
> > > > Hi,
> > > >
> > > > I have a small clarification question on To- and From header
> > > > comparision.
> > > >
> > > > Chapter 8.2.6.2 says:
> > > >
> > > > "The From field of the response MUST equal the From header field of
> > > > the request."
> > > >
> > > > Later in the chapter it explains the use of tags.
> > > >
> > > > However, there is nothing said (not in the URI comparision chapter
> > > > either) about the "<" and ">" characters, so my question is:
> > > >
> > > > If the UAC doesn't include "<" and ">" in the request, and the UAS
DOES
> > > > include them in the response, is it a protocol error?
> > > >
> > > > example:
> > > >
> > > > Request:
> > > >
> > > > To: el.sipo@sipworld.sip
> > > >
> > > > Response:
> > > >
> > > > To: <el.sipo@sipworld.sip>
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 05:57:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11554
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 05:57:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA06363
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 05:57:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04780;
	Fri, 10 May 2002 05:18:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04749
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 05:18:22 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11143
	for <sip@ietf.org>; Fri, 10 May 2002 05:18:12 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4A9IJ0E013225;
	Fri, 10 May 2002 11:18:20 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4A9IJ9q001807;
	Fri, 10 May 2002 12:18:19 +0300 (EET DST)
Message-ID: <3CDB905B.4CA150B7@lmf.ericsson.se>
Date: Fri, 10 May 2002 12:18:19 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: vishal <vishal@knowsys.net>
CC: Madhusudhan <madhusudhan@knowsys.net>, sip@ietf.org
Subject: Re: [Sip] Header comparision
References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Hi,

I know what chapter 8.2.6.2 says, but my question was if it really also affects
the angle brackets.

Another related issue: chapter 19.1.4 says that the uri parameter ordering is
not significant for URI comparision, but according to chapter 8.2.6.2 the uri
parameter ordering would have to match in a request/response transaction.

Also, from a URI comparision point of view, some parts of the URI are
case-insensitive. But, does it mean that within a transaction everything is
case-sensitive?

Regards,

Christer Holmberg
Ericsson Finland




vishal wrote:

> Hi christer,
>     From,To,Call-Id ,Cseq fields of sip response MUST exactly match
> corresponding request.If it does not match exactly ,then it should be
> protocol error .
>
> Reason:
>    you dont require addition checking while copying these fields .
>
> case you described ,
> To: el.sipo@sipworld.sip and
> To: <el.sipo@sipworld.sip>  are equivalent ,not equal.
>
> please refer to sip bis 09  section 8.2.6.2 below
>
> "8.2.6.2 Headers and Tags
>
>    The From field of the response MUST equal the From header field of
>    the request. The Call-ID header field of the response MUST equal the
>    Call-ID header field of the request. The CSeq header field of the
>    response MUST equal the CSeq field of the request. The Via header
>    field values in the response MUST equal the Via header field values
>    in the request and MUST maintain the same ordering.
>
>    If a request contained a To tag in the request, the To header field
>    in the response MUST equal that of the request. However, if the To
>    header field in the request did not contain a tag, the URI in the To
>    header field in the response MUST equal the URI in the To header
>    field; additionally, the UAS MUST add a tag to the To header field in
>    the response (with the exception of the 100 (Trying) response, in
>    which a tag MAY be present)"
>
> regards, vishal
>
> ----- Original Message -----
> From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
> To: Madhusudhan <madhusudhan@knowsys.net>
> Cc: <sip@ietf.org>
> Sent: Friday, May 10, 2002 1:35 PM
> Subject: Re: [Sip] Header comparision
>
> >
> > Hi Madhusudhan,
> >
> > Thanks for your comments!
> >
> > However, I think we are talking about two separate issues.
> >
> > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle
> brackets,
> > but that does NOT mean you aren't allowed to enclose the URI in angle
> brackets
> > ALSO in other cases. For example:
> >
> > To: <sip:el.sipo@sipworld.com>
> >
> > ...is allowed from a SIP syntax point of view.
> >
> > However, my question was related to the COMPARISION of headers.
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> > Madhusudhan wrote:
> >
> > > Hi
> > >
> > > Section 20 of bis09 mentions
> > >
> > >   "The Contact, From, and To header fields contain a URI. If the URI
> > >    contains a comma, question mark or semicolon, the URI MUST be
> > >    enclosed in angle brackets (< and >). Any URI parameters are
> > >    contained within these brackets. If the URI is not enclosed in angle
> > >    brackets, any semicolon-delimited parameters are header-parameters,
> > >    not URI parameters"
> > >
> > >  From the above comments, I think it is evident that the two addresses
> are
> > > different.
> > >
> > > correct me if I am wrong!!!
> > >
> > > Regards
> > >
> > > Madhusudhan
> > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> > > > To: <sip@ietf.org>
> > > > Sent: Friday, May 10, 2002 12:11 PM
> > > > Subject: [Sip] Header comparision
> > > >
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I have a small clarification question on To- and From header
> > > > > comparision.
> > > > >
> > > > > Chapter 8.2.6.2 says:
> > > > >
> > > > > "The From field of the response MUST equal the From header field of
> > > > > the request."
> > > > >
> > > > > Later in the chapter it explains the use of tags.
> > > > >
> > > > > However, there is nothing said (not in the URI comparision chapter
> > > > > either) about the "<" and ">" characters, so my question is:
> > > > >
> > > > > If the UAC doesn't include "<" and ">" in the request, and the UAS
> DOES
> > > > > include them in the response, is it a protocol error?
> > > > >
> > > > > example:
> > > > >
> > > > > Request:
> > > > >
> > > > > To: el.sipo@sipworld.sip
> > > > >
> > > > > Response:
> > > > >
> > > > > To: <el.sipo@sipworld.sip>
> > > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 06:04:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11746
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 06:04:06 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA07123
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 06:04:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05139;
	Fri, 10 May 2002 05:30:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05091
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 05:30:00 -0400 (EDT)
Received: from nghmail ([63.104.239.70])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11254
	for <sip@ietf.org>; Fri, 10 May 2002 05:29:51 -0400 (EDT)
Received: (qmail 22802 invoked from network); 10 May 2002 10:30:32 -0000
Received: from unknown (HELO MC11VOIP) (61.11.57.39)
  by nghmail with SMTP; 10 May 2002 10:30:32 -0000
Message-ID: <001101c1f805$4a4d7640$5601a8c0@knowsys.net>
From: "vishal" <vishal@knowsys.net>
To: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
Cc: <sip@ietf.org>
References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> <3CDB905B.4CA150B7@lmf.ericsson.se>
Subject: Re: [Sip] Header comparision
Date: Fri, 10 May 2002 15:00:07 +0530
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi christer ,
   I am trying to say that ....YES IT REALLY MATTERS ,if From field does not
exactly matches then it is an error .Another question is ....why UAS will
add angular brackets  ...and why UAC will further check different syntax
available after receiving message sent by UAS??

best solution is to compare From field as was sent in initial request .

regards, vishal






----- Original Message -----
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
To: vishal <vishal@knowsys.net>
Cc: Madhusudhan <madhusudhan@knowsys.net>; <sip@ietf.org>
Sent: Friday, May 10, 2002 2:48 PM
Subject: Re: [Sip] Header comparision


>
> Hi,
>
> I know what chapter 8.2.6.2 says, but my question was if it really also
affects
> the angle brackets.
>
> Another related issue: chapter 19.1.4 says that the uri parameter ordering
is
> not significant for URI comparision, but according to chapter 8.2.6.2 the
uri
> parameter ordering would have to match in a request/response transaction.
>
> Also, from a URI comparision point of view, some parts of the URI are
> case-insensitive. But, does it mean that within a transaction everything
is
> case-sensitive?
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
>
>
>
> vishal wrote:
>
> > Hi christer,
> >     From,To,Call-Id ,Cseq fields of sip response MUST exactly match
> > corresponding request.If it does not match exactly ,then it should be
> > protocol error .
> >
> > Reason:
> >    you dont require addition checking while copying these fields .
> >
> > case you described ,
> > To: el.sipo@sipworld.sip and
> > To: <el.sipo@sipworld.sip>  are equivalent ,not equal.
> >
> > please refer to sip bis 09  section 8.2.6.2 below
> >
> > "8.2.6.2 Headers and Tags
> >
> >    The From field of the response MUST equal the From header field of
> >    the request. The Call-ID header field of the response MUST equal the
> >    Call-ID header field of the request. The CSeq header field of the
> >    response MUST equal the CSeq field of the request. The Via header
> >    field values in the response MUST equal the Via header field values
> >    in the request and MUST maintain the same ordering.
> >
> >    If a request contained a To tag in the request, the To header field
> >    in the response MUST equal that of the request. However, if the To
> >    header field in the request did not contain a tag, the URI in the To
> >    header field in the response MUST equal the URI in the To header
> >    field; additionally, the UAS MUST add a tag to the To header field in
> >    the response (with the exception of the 100 (Trying) response, in
> >    which a tag MAY be present)"
> >
> > regards, vishal
> >
> > ----- Original Message -----
> > From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
> > To: Madhusudhan <madhusudhan@knowsys.net>
> > Cc: <sip@ietf.org>
> > Sent: Friday, May 10, 2002 1:35 PM
> > Subject: Re: [Sip] Header comparision
> >
> > >
> > > Hi Madhusudhan,
> > >
> > > Thanks for your comments!
> > >
> > > However, I think we are talking about two separate issues.
> > >
> > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle
> > brackets,
> > > but that does NOT mean you aren't allowed to enclose the URI in angle
> > brackets
> > > ALSO in other cases. For example:
> > >
> > > To: <sip:el.sipo@sipworld.com>
> > >
> > > ...is allowed from a SIP syntax point of view.
> > >
> > > However, my question was related to the COMPARISION of headers.
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > > Madhusudhan wrote:
> > >
> > > > Hi
> > > >
> > > > Section 20 of bis09 mentions
> > > >
> > > >   "The Contact, From, and To header fields contain a URI. If the URI
> > > >    contains a comma, question mark or semicolon, the URI MUST be
> > > >    enclosed in angle brackets (< and >). Any URI parameters are
> > > >    contained within these brackets. If the URI is not enclosed in
angle
> > > >    brackets, any semicolon-delimited parameters are
header-parameters,
> > > >    not URI parameters"
> > > >
> > > >  From the above comments, I think it is evident that the two
addresses
> > are
> > > > different.
> > > >
> > > > correct me if I am wrong!!!
> > > >
> > > > Regards
> > > >
> > > > Madhusudhan
> > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> > > > > To: <sip@ietf.org>
> > > > > Sent: Friday, May 10, 2002 12:11 PM
> > > > > Subject: [Sip] Header comparision
> > > > >
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have a small clarification question on To- and From header
> > > > > > comparision.
> > > > > >
> > > > > > Chapter 8.2.6.2 says:
> > > > > >
> > > > > > "The From field of the response MUST equal the From header field
of
> > > > > > the request."
> > > > > >
> > > > > > Later in the chapter it explains the use of tags.
> > > > > >
> > > > > > However, there is nothing said (not in the URI comparision
chapter
> > > > > > either) about the "<" and ">" characters, so my question is:
> > > > > >
> > > > > > If the UAC doesn't include "<" and ">" in the request, and the
UAS
> > DOES
> > > > > > include them in the response, is it a protocol error?
> > > > > >
> > > > > > example:
> > > > > >
> > > > > > Request:
> > > > > >
> > > > > > To: el.sipo@sipworld.sip
> > > > > >
> > > > > > Response:
> > > > > >
> > > > > > To: <el.sipo@sipworld.sip>
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Christer Holmberg
> > > > > > Ericsson Finland
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 06:39:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12868
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 06:39:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA08799
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 06:39:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06286;
	Fri, 10 May 2002 05:56:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA06252
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 05:56:18 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11534
	for <sip@ietf.org>; Fri, 10 May 2002 05:56:08 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4A9tWk29355
	for <sip@ietf.org>; Fri, 10 May 2002 12:56:31 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5ac6db34c9ac158f24077@esvir04nok.ntc.nokia.com>;
 Fri, 10 May 2002 12:55:11 +0300
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Fri, 10 May 2002 12:55:10 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Fri, 10 May 2002 12:55:10 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path needed?
Date: Fri, 10 May 2002 12:55:09 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB777919A@esebe019.NOE.Nokia.com>
Thread-Topic: WGLC for draft-willis-sip-path-05: Require:path needed?
Thread-Index: AcH1944mM8TlXyXOSsKsfep6ee8gkAAc1vhAAAYg12AAARtQgABgDDcg
To: <bernhard.honeisen@nokia.com>, <dean.willis@softarmor.com>,
        <bpenfield@acmepacket.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 10 May 2002 09:55:10.0382 (UTC) FILETIME=[C5BA1CE0:01C1F808]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA06253
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: Honeisen Bernhard (NET/Helsinki) 
> Sent: Wednesday, May 08, 2002 4:11 PM
> To: Khartabil Hisham (NMP/Helsinki); 'dean.willis@softarmor.com';
> 'bpenfield@acmepacket.com'
> Cc: 'sip@ietf.org'
> Subject: RE: [Sip] RE: WGLC for draft-willis-sip-path-05: Require:path
> needed?

> > > Solution:
> > > 
> > > -> after a 420 the UA tries to send the request without
> > > Supported:path.
> > > 
> > > -> Proxies MUST NOT insert a Require:path, if no Supported:path
> > > was present in the request.
> > 
> > 
> > 
> > Are you suggesting that a proxy must remember requests that 
> > it processed earlier?
> 
> No, not at all. Why do you think it has to remember?
> 
> > First you mention that a proxy can insert a path-header 
> > without a supported-header (or that is what it sounded like 
> > at least).
> 
> If it does, the registrar will ignore any Path header, as 
> no Supported:path is present in the REGISTER request in
> question. Such behaviour would allow easier implementation
> of proxies. (But I don't argue, if people think it's better,
> if proxies must not insert any Path stuff, if there is
> no Supported header in the REGISTER request in question.)
> My proposal is just, that the proxy just MUST NOT insert
> any Require:path, if Supported:path was not present.
> 

Ok, now I understand what your saying ;) But what is the point (besides ease of implementation) of allowing proxies to add a path-header for a request (REGISTER) that does not contain a "supported: path" header if the registrar is going to ignore them anyway? The SIP message size gets bigger and bigger for no reason.

Regards,
Hisham

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



From daemon@optimus.ietf.org  Fri May 10 06:39:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12895
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 06:39:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA08814
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 06:39:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05982;
	Fri, 10 May 2002 05:47:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA05951
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 05:46:59 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11436
	for <sip@ietf.org>; Fri, 10 May 2002 05:46:47 -0400 (EDT)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4A9kGI18166;
	Fri, 10 May 2002 11:46:17 +0200 (MEST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KHH1QXHX>; Fri, 10 May 2002 10:46:51 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F71FC@zwcwd00r.europe.nortel.com>
From: "Mark Watson"<mwatson@nortelnetworks.com>
To: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Rosen, Brian'"
	 <Brian.Rosen@marconi.com>, sip@ietf.org
Subject: RE: [Sip] Network Asserted Identity
Date: Fri, 10 May 2002 10:46:45 +0100
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

So, all votes so far are for 'Asserted-Identity'.

To answer the obvious 'asserted by whom ?' question, I suggest some text
along the following lines (for Cullen's draft, not the requirements):

'In the absence of other indications, a node receiving an Asserted-Identity
header must assume that it is asserted by the node from which it was
received (assuming integrity protection on this hop). This does not by
itself imply that the sending node has the right to assert the identity, or
that the identity has any validity.

So, for example, if the nodes are members of the same Trust Domain and the
receiving node trusts the node from which the Asserted-Identity was received
(in the sense of [nai-reqs]), then the sending node can be assumed to have
the right to assert identities on behalf of the Trust Domain. In this case
the Asserted-Identity is a Network Asserted Identity as defined in
[nai-reqs].

Alternatively, if a proxy receives an Asserted-Identity header from a UA,
then the Asserted-Identity represents only the UA's preference as to its
identity for Network Asserted Identity purposes. As with any header, in the
absence of some integrity protection between the UA and the proxy, there is
no guarantee that the identity has not been modified in transit.'

I will also update the requirements to include the 'hint' case.

Regards,

Mark

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 09 May 2002 20:09
> To: 'Rosen, Brian'; Watson, Mark [MDN05:EP10:EXCH]; sip@ietf.org
> Subject: RE: [Sip] Network Asserted Identity
> 
> 
> > On the hint, I don't understand why From isn't the hint.  
> > Could you explain? Assuming there is a good reason, I'd use 
> > the same header name.  
> > That kind of makes Asserted-Identity a better choice.
> 
> From: isn't the hint because there may need to be network assertion of
> identity even when there is a privacy request from the user. Unless we
> want proxies munging From: (insert my many arguments here) 
> then the hint
> needs to be in another place that CAN be proxy-munged. This leaves the
> UA responsible for its From: field (sets "anonymous" or equiavelent if
> privacy required) which is cleaner and has better
> backward-compatibility.
> 
> I like "Asserted-Identity", as future techniques lets us say WHO
> asserted the identity, and it might be "the network", the user, or a
> third-party authentication service.
> 
> --
> 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 daemon@optimus.ietf.org  Fri May 10 07:01:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13779
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 07:01:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA09888
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 07:01:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07389;
	Fri, 10 May 2002 06:09:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07292
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 06:09:39 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11896
	for <sip@ietf.org>; Fri, 10 May 2002 06:09:29 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4AA9b0E000598;
	Fri, 10 May 2002 12:09:37 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4AA9a9q002988;
	Fri, 10 May 2002 13:09:37 +0300 (EET DST)
Message-ID: <3CDB9C61.3FF7FC4F@lmf.ericsson.se>
Date: Fri, 10 May 2002 13:09:37 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: vishal <vishal@knowsys.net>
CC: sip@ietf.org
Subject: Re: [Sip] Header comparision
References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> <3CDB905B.4CA150B7@lmf.ericsson.se> <001101c1f805$4a4d7640$5601a8c0@knowsys.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Hi,

> Hi christer ,
>    I am trying to say that ....YES IT REALLY MATTERS ,if From field does not
> exactly matches then it is an error .Another question is ....why UAS will
> add angular brackets  ...and why UAC will further check different syntax
> available after receiving message sent by UAS??
>
> best solution is to compare From field as was sent in initial request .

Yes, you can do a pure binary comparision, but that also requires the order the
uri parameters are the same, there is no case difference etc.

Why I would want to do this or that (I didn't even said I would) really doesn't
matter. I am just trying to get a clarification on the angle bracket case, the
uri parameter order case, and the case sensitivity case, for header mapping
within a transaction...

Regards,

Christer Holmberg
Ericsson Finland




>
>
> regards, vishal
>
> ----- Original Message -----
> From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
> To: vishal <vishal@knowsys.net>
> Cc: Madhusudhan <madhusudhan@knowsys.net>; <sip@ietf.org>
> Sent: Friday, May 10, 2002 2:48 PM
> Subject: Re: [Sip] Header comparision
>
> >
> > Hi,
> >
> > I know what chapter 8.2.6.2 says, but my question was if it really also
> affects
> > the angle brackets.
> >
> > Another related issue: chapter 19.1.4 says that the uri parameter ordering
> is
> > not significant for URI comparision, but according to chapter 8.2.6.2 the
> uri
> > parameter ordering would have to match in a request/response transaction.
> >
> > Also, from a URI comparision point of view, some parts of the URI are
> > case-insensitive. But, does it mean that within a transaction everything
> is
> > case-sensitive?
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> >
> > vishal wrote:
> >
> > > Hi christer,
> > >     From,To,Call-Id ,Cseq fields of sip response MUST exactly match
> > > corresponding request.If it does not match exactly ,then it should be
> > > protocol error .
> > >
> > > Reason:
> > >    you dont require addition checking while copying these fields .
> > >
> > > case you described ,
> > > To: el.sipo@sipworld.sip and
> > > To: <el.sipo@sipworld.sip>  are equivalent ,not equal.
> > >
> > > please refer to sip bis 09  section 8.2.6.2 below
> > >
> > > "8.2.6.2 Headers and Tags
> > >
> > >    The From field of the response MUST equal the From header field of
> > >    the request. The Call-ID header field of the response MUST equal the
> > >    Call-ID header field of the request. The CSeq header field of the
> > >    response MUST equal the CSeq field of the request. The Via header
> > >    field values in the response MUST equal the Via header field values
> > >    in the request and MUST maintain the same ordering.
> > >
> > >    If a request contained a To tag in the request, the To header field
> > >    in the response MUST equal that of the request. However, if the To
> > >    header field in the request did not contain a tag, the URI in the To
> > >    header field in the response MUST equal the URI in the To header
> > >    field; additionally, the UAS MUST add a tag to the To header field in
> > >    the response (with the exception of the 100 (Trying) response, in
> > >    which a tag MAY be present)"
> > >
> > > regards, vishal
> > >
> > > ----- Original Message -----
> > > From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
> > > To: Madhusudhan <madhusudhan@knowsys.net>
> > > Cc: <sip@ietf.org>
> > > Sent: Friday, May 10, 2002 1:35 PM
> > > Subject: Re: [Sip] Header comparision
> > >
> > > >
> > > > Hi Madhusudhan,
> > > >
> > > > Thanks for your comments!
> > > >
> > > > However, I think we are talking about two separate issues.
> > > >
> > > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle
> > > brackets,
> > > > but that does NOT mean you aren't allowed to enclose the URI in angle
> > > brackets
> > > > ALSO in other cases. For example:
> > > >
> > > > To: <sip:el.sipo@sipworld.com>
> > > >
> > > > ...is allowed from a SIP syntax point of view.
> > > >
> > > > However, my question was related to the COMPARISION of headers.
> > > >
> > > > Regards,
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > >
> > > > Madhusudhan wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > Section 20 of bis09 mentions
> > > > >
> > > > >   "The Contact, From, and To header fields contain a URI. If the URI
> > > > >    contains a comma, question mark or semicolon, the URI MUST be
> > > > >    enclosed in angle brackets (< and >). Any URI parameters are
> > > > >    contained within these brackets. If the URI is not enclosed in
> angle
> > > > >    brackets, any semicolon-delimited parameters are
> header-parameters,
> > > > >    not URI parameters"
> > > > >
> > > > >  From the above comments, I think it is evident that the two
> addresses
> > > are
> > > > > different.
> > > > >
> > > > > correct me if I am wrong!!!
> > > > >
> > > > > Regards
> > > > >
> > > > > Madhusudhan
> > > > >
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> > > > > > To: <sip@ietf.org>
> > > > > > Sent: Friday, May 10, 2002 12:11 PM
> > > > > > Subject: [Sip] Header comparision
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I have a small clarification question on To- and From header
> > > > > > > comparision.
> > > > > > >
> > > > > > > Chapter 8.2.6.2 says:
> > > > > > >
> > > > > > > "The From field of the response MUST equal the From header field
> of
> > > > > > > the request."
> > > > > > >
> > > > > > > Later in the chapter it explains the use of tags.
> > > > > > >
> > > > > > > However, there is nothing said (not in the URI comparision
> chapter
> > > > > > > either) about the "<" and ">" characters, so my question is:
> > > > > > >
> > > > > > > If the UAC doesn't include "<" and ">" in the request, and the
> UAS
> > > DOES
> > > > > > > include them in the response, is it a protocol error?
> > > > > > >
> > > > > > > example:
> > > > > > >
> > > > > > > Request:
> > > > > > >
> > > > > > > To: el.sipo@sipworld.sip
> > > > > > >
> > > > > > > Response:
> > > > > > >
> > > > > > > To: <el.sipo@sipworld.sip>
> > > > > > >
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Christer Holmberg
> > > > > > > Ericsson Finland
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > > > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 08:12:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17055
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 08:12:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA12381
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:12:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11467;
	Fri, 10 May 2002 07:47:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08913
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 06:40:20 -0400 (EDT)
Received: from hotmail.com (f8.law11.hotmail.com [64.4.17.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12987
	for <sip@ietf.org>; Fri, 10 May 2002 06:40:10 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 10 May 2002 03:39:49 -0700
Received: from 47.234.0.52 by lw11fd.law11.hotmail.msn.com with HTTP;
	Fri, 10 May 2002 10:39:49 GMT
X-Originating-IP: [47.234.0.52]
From: "sushanth hegde" <sushanthh@hotmail.com>
To: sip@ietf.org
Date: Fri, 10 May 2002 10:39:49 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F8H8J0sca0ZkfzDskqC000124a4@hotmail.com>
X-OriginalArrivalTime: 10 May 2002 10:39:49.0782 (UTC) FILETIME=[02C61B60:01C1F80F]
Subject: [Sip] Queries regd sIP in 3G
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Greetings,

Few queries regarding SIP in 3GPP.

1. In a 3G architecture where exactly does  each component of a SIP Server 
(i.e Proxy,Registrar etc)
    fit in? In other words what is the mapping between SIP Server 
Architecture and 3G Architecture

2. Does the SIP User Agent Reside in the 3G enabled Mobile phone? if not 
where does a SIP User Agent
   reside?

3. Any reference sites which gives me more information regarding SIP in 3G.
Thank you in Anticipation.
Regards,
Sushanth

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.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 daemon@optimus.ietf.org  Fri May 10 08:38:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18290
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 08:38:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA13537
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:38:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12747;
	Fri, 10 May 2002 08:26:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12709
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 08:26:11 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17664
	for <sip@ietf.org>; Fri, 10 May 2002 08:26:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA27963
	for <sip@ietf.org>; Fri, 10 May 2002 08:25:38 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA20332
	for <sip@ietf.org>; Fri, 10 May 2002 08:25:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <J79SW22Z>; Fri, 10 May 2002 08:25:39 -0400
Message-ID: <313680C9A886D511A06000204840E1CF030B52DB@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Fri, 10 May 2002 08:25:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [Sip] UPDATE and Expires
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This morning, I arrived to find an experimental SIP implementation 
was "ringing" all night.  It's experimental.  The UAC that called
me died in the middle of the transaction.  Still, my end should
have given up the call at some point.  I go looking for the
codesmith.

The programmer says "That's correct behavior.  Just because the 
caller died, the UAS got an INVITE, and is waiting for the user to 
answer before it sends the 200 OK.  Since this is user time, 
there is no good time after which it is okay to abandon the call"

I protest "But the UAC died!"

And the programmer says "The UAS doesn't know that, as far as it knows,
the user at the UAS wants it to keep ringing"

And I reach for my copy of bis-09 and say "Ah Ha, why don't we put
an Expire header on the Invite, and send 487 if it expires.  And
CANCEL to boot?"

And he says "Sure, but what if the user at the UAC WANTS to wait
longer than whatever the Expires says"

And I reach for my copy of update-02, ready to say "Send an UPDATE
and extend the Expire", but, alas, Expire is not legal on
Update.

And so I wrote this email

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 daemon@optimus.ietf.org  Fri May 10 08:51:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19102
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 08:51:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA13925
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:51:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12620;
	Fri, 10 May 2002 08:23:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA12593
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 08:23:33 -0400 (EDT)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17485
	for <sip@ietf.org>; Fri, 10 May 2002 08:23:24 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4ACKSu2007073;
	Fri, 10 May 2002 08:20:28 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <JKJLG60A>; Fri, 10 May 2002 08:23:01 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36B4759@DYN-TX-EXCH-001.dynamicsoft.com>
From: Andrew Allen <AAllen@dynamicsoft.com>
To: "'sushanth hegde'" <sushanthh@hotmail.com>, sip@ietf.org
Subject: RE: [Sip] Queries regd sIP in 3G
Date: Fri, 10 May 2002 08:22:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


For 3GPP:

> -----Original Message-----
> From: sushanth hegde [mailto:sushanthh@hotmail.com]
> Sent: Friday, May 10, 2002 5:40 AM
> To: sip@ietf.org
> Subject: [Sip] Queries regd sIP in 3G
> 
> 
> Greetings,
> 
> Few queries regarding SIP in 3GPP.
> 
> 1. In a 3G architecture where exactly does  each component of 
> a SIP Server 
> (i.e Proxy,Registrar etc)
>     fit in? In other words what is the mapping between SIP Server 
> Architecture and 3G Architecture

Best to see TS 24.229 for full explanation
http://www.3gpp.org/ftp/specs/latest/Rel-5/24_series/24229-500.zip
> 
> 2. Does the SIP User Agent Reside in the 3G enabled Mobile 
> phone? if not 
> where does a SIP User Agent
>    reside?
> 
Yes a SIP UA resides in the UE (mobile phone)

> 3. Any reference sites which gives me more information 
> regarding SIP in 3G.
> Thank you in Anticipation.
> Regards,
> Sushanth

Architecture:
http://www.3gpp.org/ftp/specs/latest/Rel-5/23_series/23228-530.zip
Call Model:
http://www.3gpp.org/ftp/specs/latest/Rel-5/23_series/23218-500.zip
Session Flows:
http://www.3gpp.org/ftp/specs/latest/Rel-5/24_series/24228-500.zip
Protocol:
http://www.3gpp.org/ftp/specs/latest/Rel-5/24_series/24229-500.zip

Note that the 24 series specs are not yet fully completed and may contain
out of date/wrong information and the version numbers (i.e 24229-500) will
change after June (to 24.229-510)
> 
> _________________________________________________________________
> Join the world's largest e-mail service with MSN Hotmail. 
> http://www.hotmail.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 daemon@optimus.ietf.org  Fri May 10 08:57:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19487
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 08:57:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA14068
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 08:57:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13586;
	Fri, 10 May 2002 08:38:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA13558
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 08:38:47 -0400 (EDT)
Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18319
	for <sip@ietf.org>; Fri, 10 May 2002 08:38:37 -0400 (EDT)
From: duncan.mills@vf.vodafone.co.uk
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id NAA30142; Fri, 10 May 2002 13:38:15 +0100 (BST)
Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67])
	by mailguard1 (4.6.1.91) with ESMTP id 
	for <sip@ietf.org>; Fri, 10 May 2002 13:37:52 +0100
Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0016251630@mimesweeper1.vfl.vodafone> for <sip@ietf.org>;
 Fri, 10 May 2002 13:38:06 +0100
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21)
	id <K464BJZF>; Fri, 10 May 2002 13:38:06 +0100
Message-Id: <DDC3D921FB67D211AAD100A0C9E58F530B2CA0DF@hampstead.vfl.vodafone>
To: sip@ietf.org
Subject: RE: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt
Date: Fri, 10 May 2002 13:38:05 +0100
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122)
Content-Type: text/plain;	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

All,

The P-Access-Network-Info header draft (version 01) has been available for
some time now, and I have received very few comments related to it.

Does this mean there are no problems with the draft?

Regards,

Duncan

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
Sent: 03 May 2002 12:28
To: IETF-Announce
Cc: sip@ietf.org
Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: The SIP Access Network Info header
	Author(s)	: D. Mills
	Filename	: draft-mills-sip-access-network-info-01.txt
	Pages		: 5
	Date		: 02-May-02
	
This document defines the private SIP extension header
P-Access-Network-Info. This mechanism is useful in SIP networks that
are partitioned, such as 3G wireless networks which are partitioned at
the SIP layer into 'access' and 'home' networks. SIP User Agents may
use this header to relay information about the access network to
serving proxies in their home network. The serving proxy may then use
this information to optimize services for the UA. For example, a 3GPP
terminal uses this header to pass information about the access network
such as radio access technology and cell ID to its home service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-01.t
xt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mills-sip-access-network-info-01.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-mills-sip-access-network-info-01.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 daemon@optimus.ietf.org  Fri May 10 11:21:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28273
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 11:21:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA22517
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 11:21:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20795;
	Fri, 10 May 2002 10:59:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20766
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 10:59:48 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27009
	for <sip@ietf.org>; Fri, 10 May 2002 10:59:38 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4AExO813702;
	Fri, 10 May 2002 09:59:24 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXXPP6X>; Fri, 10 May 2002 09:59:47 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B06D@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>,
        "'sip@ietf.org'"
	 <sip@ietf.org>
Subject: RE: [Sip] UPDATE and Expires
Date: Fri, 10 May 2002 09:59:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1F833.4E79CBF0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1F833.4E79CBF0
Content-Type: text/plain;
	charset="iso-8859-1"

What if you do not control the UAC - and he does not put an Expires header
into the INVITE. Would your UAS then continue to ring for ever? I think the
implementation of the UA's will have to perform some sanity timing that is
not part of the spec (i.e. Implementation specific).

Brian - your point is still valid.

Thanks,

Sriram

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


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Friday, May 10, 2002 7:26 AM
To: 'sip@ietf.org'
Subject: [Sip] UPDATE and Expires


This morning, I arrived to find an experimental SIP implementation 
was "ringing" all night.  It's experimental.  The UAC that called
me died in the middle of the transaction.  Still, my end should
have given up the call at some point.  I go looking for the
codesmith.

The programmer says "That's correct behavior.  Just because the 
caller died, the UAS got an INVITE, and is waiting for the user to 
answer before it sends the 200 OK.  Since this is user time, 
there is no good time after which it is okay to abandon the call"

I protest "But the UAC died!"

And the programmer says "The UAS doesn't know that, as far as it knows,
the user at the UAS wants it to keep ringing"

And I reach for my copy of bis-09 and say "Ah Ha, why don't we put
an Expire header on the Invite, and send 487 if it expires.  And
CANCEL to boot?"

And he says "Sure, but what if the user at the UAC WANTS to wait
longer than whatever the Expires says"

And I reach for my copy of update-02, ready to say "Send an UPDATE
and extend the Expire", but, alas, Expire is not legal on
Update.

And so I wrote this email

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Sip] UPDATE and Expires</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>What if you do not control the UAC - and he does not =
put an Expires header into the INVITE. Would your UAS then continue to =
ring for ever? I think the implementation of the UA's will have to =
perform some sanity timing that is not part of the spec (i.e. =
Implementation specific).</FONT></P>

<P><FONT SIZE=3D2>Brian - your point is still valid.</FONT>
</P>

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

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

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

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Rosen, Brian [<A =
HREF=3D"mailto:Brian.Rosen@marconi.com">mailto:Brian.Rosen@marconi.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, May 10, 2002 7:26 AM</FONT>
<BR><FONT SIZE=3D2>To: 'sip@ietf.org'</FONT>
<BR><FONT SIZE=3D2>Subject: [Sip] UPDATE and Expires</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>This morning, I arrived to find an experimental SIP =
implementation </FONT>
<BR><FONT SIZE=3D2>was &quot;ringing&quot; all night.&nbsp; It's =
experimental.&nbsp; The UAC that called</FONT>
<BR><FONT SIZE=3D2>me died in the middle of the transaction.&nbsp; =
Still, my end should</FONT>
<BR><FONT SIZE=3D2>have given up the call at some point.&nbsp; I go =
looking for the</FONT>
<BR><FONT SIZE=3D2>codesmith.</FONT>
</P>

<P><FONT SIZE=3D2>The programmer says &quot;That's correct =
behavior.&nbsp; Just because the </FONT>
<BR><FONT SIZE=3D2>caller died, the UAS got an INVITE, and is waiting =
for the user to </FONT>
<BR><FONT SIZE=3D2>answer before it sends the 200 OK.&nbsp; Since this =
is user time, </FONT>
<BR><FONT SIZE=3D2>there is no good time after which it is okay to =
abandon the call&quot;</FONT>
</P>

<P><FONT SIZE=3D2>I protest &quot;But the UAC died!&quot;</FONT>
</P>

<P><FONT SIZE=3D2>And the programmer says &quot;The UAS doesn't know =
that, as far as it knows,</FONT>
<BR><FONT SIZE=3D2>the user at the UAS wants it to keep =
ringing&quot;</FONT>
</P>

<P><FONT SIZE=3D2>And I reach for my copy of bis-09 and say &quot;Ah =
Ha, why don't we put</FONT>
<BR><FONT SIZE=3D2>an Expire header on the Invite, and send 487 if it =
expires.&nbsp; And</FONT>
<BR><FONT SIZE=3D2>CANCEL to boot?&quot;</FONT>
</P>

<P><FONT SIZE=3D2>And he says &quot;Sure, but what if the user at the =
UAC WANTS to wait</FONT>
<BR><FONT SIZE=3D2>longer than whatever the Expires says&quot;</FONT>
</P>

<P><FONT SIZE=3D2>And I reach for my copy of update-02, ready to say =
&quot;Send an UPDATE</FONT>
<BR><FONT SIZE=3D2>and extend the Expire&quot;, but, alas, Expire is =
not legal on</FONT>
<BR><FONT SIZE=3D2>Update.</FONT>
</P>

<P><FONT SIZE=3D2>And so I wrote this email</FONT>
</P>

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

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>This list is for NEW development of the core SIP =
Protocol</FONT>
<BR><FONT SIZE=3D2>Use sip-implementors@cs.columbia.edu for questions =
on current sip</FONT>
<BR><FONT SIZE=3D2>Use sipping@ietf.org for new developments on the =
application of sip</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F833.4E79CBF0--

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



From daemon@optimus.ietf.org  Fri May 10 11:35:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29200
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 11:35:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA24030
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 11:36:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22286;
	Fri, 10 May 2002 11:17:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22255
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 11:17:45 -0400 (EDT)
Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28018
	for <sip@ietf.org>; Fri, 10 May 2002 11:17:35 -0400 (EDT)
Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116])
	by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4AFHcX27906;
	Fri, 10 May 2002 11:17:38 -0400 (EDT)
Message-ID: <00cf01c1f835$d2469240$743c0198@ecew2k.ncsu.edu>
From: "Prabhas Sinha" <prsinha@unity.ncsu.edu>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>, <sip@ietf.org>
References: <313680C9A886D511A06000204840E1CF030B52DB@whq-msgusr-02.pit.comms.marconi.com>
Subject: Re: [Sip] UPDATE and Expires
Date: Fri, 10 May 2002 11:17:38 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I would second Brian's suggestion in this case. We should make use of a
timer (which can be configured by the user in the UAC -- very much like
number of rings in a PSTN phone beforethe control goes to the answering
machine) so that the phone doesnt keep ringing all night or for that matter
whole month if Brian is vacationing :-)

> And he says "Sure, but what if the user at the UAC WANTS to wait
> longer than whatever the Expires says"
>

this doesnt make sense. In a PSTN line you know that if the call is not
picked up in 5 rings, then it goes to the answering machine. If the UAC
wants to wait longer then he should adjust the timer of the UAC accordingly.

> And I reach for my copy of update-02, ready to say "Send an UPDATE
> and extend the Expire", but, alas, Expire is not legal on
> Update.
>

is it really neccessary to do this ? think of the overheads in real time
scenario. Most of the time this will happen when the user is not on his
seat, a very few times he would want to wait longer so why to complicate the
matter ?

I still feel that a use of a simple counter at the UAC should suffice.

Any further thoughts ?

Thanx,
Prabhas.

----- Original Message -----
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: <sip@ietf.org>
Sent: Friday, May 10, 2002 8:25 AM
Subject: [Sip] UPDATE and Expires


> This morning, I arrived to find an experimental SIP implementation
> was "ringing" all night.  It's experimental.  The UAC that called
> me died in the middle of the transaction.  Still, my end should
> have given up the call at some point.  I go looking for the
> codesmith.
>
> The programmer says "That's correct behavior.  Just because the
> caller died, the UAS got an INVITE, and is waiting for the user to
> answer before it sends the 200 OK.  Since this is user time,
> there is no good time after which it is okay to abandon the call"
>
> I protest "But the UAC died!"
>
> And the programmer says "The UAS doesn't know that, as far as it knows,
> the user at the UAS wants it to keep ringing"
>
> And I reach for my copy of bis-09 and say "Ah Ha, why don't we put
> an Expire header on the Invite, and send 487 if it expires.  And
> CANCEL to boot?"
>
> And he says "Sure, but what if the user at the UAC WANTS to wait
> longer than whatever the Expires says"
>
> And I reach for my copy of update-02, ready to say "Send an UPDATE
> and extend the Expire", but, alas, Expire is not legal on
> Update.
>
> And so I wrote this email
>
> 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 daemon@optimus.ietf.org  Fri May 10 12:31:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02868
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 12:31:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA28128
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 12:31:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26600;
	Fri, 10 May 2002 12:08:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26568
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 12:08:34 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01255
	for <sip@ietf.org>; Fri, 10 May 2002 12:08:23 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4AG83d13632;
	Fri, 10 May 2002 11:08:03 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'sushanth hegde'" <sushanthh@hotmail.com>, <sip@ietf.org>
Subject: RE: [Sip] Queries regd sIP in 3G
Date: Fri, 10 May 2002 11:07:43 -0500
Message-ID: <005c01c1f83c$d16a37d0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-reply-to: <F8H8J0sca0ZkfzDskqC000124a4@hotmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of sushanth hegde
> Sent: Friday, May 10, 2002 5:40 AM
> To: sip@ietf.org
> Subject: [Sip] Queries regd sIP in 3G
> 
> 
> Greetings,
> 
> Few queries regarding SIP in 3GPP.
> 
> 1. In a 3G architecture where exactly does  each component of 
> a SIP Server 
> (i.e Proxy,Registrar etc)
>     fit in? In other words what is the mapping between SIP Server 
> Architecture and 3G Architecture

Depends on which 3G architecture. 3GPP and 3GPP2 are slightly different.

> 
> 2. Does the SIP User Agent Reside in the 3G enabled Mobile 
> phone? if not 
> where does a SIP User Agent
>    reside?

Yes, for both 3GPP and 3GPP2. Ther MAY also be a UA in other locations.
 
> 3. Any reference sites which gives me more information 
> regarding SIP in 3G. Thank you in Anticipation. Regards, Sushanth

http://www.3gpp.org/

http://www.3gpp2.org/

There should also be a nice tutorial presentation made by Arjun during
the SIP Summit earlier this week, available soon at
http://www.pulver.com/

--
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 daemon@optimus.ietf.org  Fri May 10 12:39:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03554
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 12:39:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA28597
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 12:39:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26697;
	Fri, 10 May 2002 12:09:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26667
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 12:09:56 -0400 (EDT)
Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01329
	for <sip@ietf.org>; Fri, 10 May 2002 12:09:45 -0400 (EDT)
Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44])
	by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id LAA02503
	for <sip@ietf.org>; Fri, 10 May 2002 11:15:49 -0500
Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com
 (Content Technologies SMTPRS 4.2.10) with SMTP id <T5ac676a90197d65a2c398@DALNTMS02.ivbi.com> for <sip@ietf.org>;
 Fri, 10 May 2002 11:05:21 -0500
Received: from bculpepperpc
	([151.214.151.115])
	by 172.16.16.64; Fri, 10 May 2002 11:09:10 -0500
From: "Bert Culpepper" <bert.culpepper@intervoice-brite.com>
To: "'Prabhas Sinha'" <prsinha@unity.ncsu.edu>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>, <sip@ietf.org>
Subject: RE: [Sip] UPDATE and Expires
Date: Fri, 10 May 2002 12:08:33 -0400
Message-ID: <006901c1f83c$efc0ca00$7397d697@bculpepperpc>
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 CWS, Build 9.0.2416 (9.0.2911.0)
In-reply-to: <00cf01c1f835$d2469240$743c0198@ecew2k.ncsu.edu>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

comment inline...

Prabhas Sinha wrote:
>
> I would second Brian's suggestion in this case. We should
> make use of a
> timer (which can be configured by the user in the UAC -- very
> much like
> number of rings in a PSTN phone beforethe control goes to the
> answering
> machine) so that the phone doesnt keep ringing all night or
> for that matter
> whole month if Brian is vacationing :-)
>
> > And he says "Sure, but what if the user at the UAC WANTS to wait
> > longer than whatever the Expires says"
> >
>
> this doesnt make sense. In a PSTN line you know that if the
> call is not
> picked up in 5 rings, then it goes to the answering machine.
> If the UAC
> wants to wait longer then he should adjust the timer of the
> UAC accordingly.

I agree, see below.

>
> > And I reach for my copy of update-02, ready to say "Send an UPDATE
> > and extend the Expire", but, alas, Expire is not legal on
> > Update.
> >
>
> is it really neccessary to do this ? think of the overheads
> in real time
> scenario. Most of the time this will happen when the user is
> not on his
> seat, a very few times he would want to wait longer so why to
> complicate the
> matter ?

I would think the caller will have an idea of how long he/she wants to wait
for answer, and set the value of the Expires header accordingly in the
INVITE request.  However, if the caller's UA doesn't support this and it
crashes, then I believe it's an implementation issue for the UAS.  Or when
the callee answers the call, current defined protocol behavior (no ACK
received) will suffice here.

Regards,
Bert

>
> I still feel that a use of a simple counter at the UAC should suffice.
>
> Any further thoughts ?
>
> Thanx,
> Prabhas.
>
> ----- Original Message -----
> From: "Rosen, Brian" <Brian.Rosen@marconi.com>
> To: <sip@ietf.org>
> Sent: Friday, May 10, 2002 8:25 AM
> Subject: [Sip] UPDATE and Expires
>
>
> > This morning, I arrived to find an experimental SIP implementation
> > was "ringing" all night.  It's experimental.  The UAC that called
> > me died in the middle of the transaction.  Still, my end should
> > have given up the call at some point.  I go looking for the
> > codesmith.
> >
> > The programmer says "That's correct behavior.  Just because the
> > caller died, the UAS got an INVITE, and is waiting for the user to
> > answer before it sends the 200 OK.  Since this is user time,
> > there is no good time after which it is okay to abandon the call"
> >
> > I protest "But the UAC died!"
> >
> > And the programmer says "The UAS doesn't know that, as far
> as it knows,
> > the user at the UAS wants it to keep ringing"
> >
> > And I reach for my copy of bis-09 and say "Ah Ha, why don't we put
> > an Expire header on the Invite, and send 487 if it expires.  And
> > CANCEL to boot?"
> >
> > And he says "Sure, but what if the user at the UAC WANTS to wait
> > longer than whatever the Expires says"
> >
> > And I reach for my copy of update-02, ready to say "Send an UPDATE
> > and extend the Expire", but, alas, Expire is not legal on
> > Update.
> >
> > And so I wrote this email
> >
> > 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 daemon@optimus.ietf.org  Fri May 10 13:33:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06883
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 13:33:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA01955
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 13:33:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00051;
	Fri, 10 May 2002 13:05:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00022
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 13:05:51 -0400 (EDT)
Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05183
	for <sip@ietf.org>; Fri, 10 May 2002 13:05:41 -0400 (EDT)
Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116])
	by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4AH5nK23690;
	Fri, 10 May 2002 13:05:50 -0400 (EDT)
Message-ID: <01f301c1f844$ef57fc70$743c0198@ecew2k.ncsu.edu>
From: "Prabhas Sinha" <prsinha@unity.ncsu.edu>
To: "Bert Culpepper" <bert.culpepper@intervoice-brite.com>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>, <sip@ietf.org>
References: <006901c1f83c$efc0ca00$7397d697@bculpepperpc>
Subject: Re: [Sip] UPDATE and Expires
Date: Fri, 10 May 2002 13:05:49 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> I would think the caller will have an idea of how long he/she wants to
wait
> for answer, and set the value of the Expires header accordingly in the
> INVITE request.  However, if the caller's UA doesn't support this and it
> crashes, then I believe it's an implementation issue for the UAS.  Or when
> the callee answers the call, current defined protocol behavior (no ACK
> received) will suffice here.
>
> Regards,
> Bert
>

on the contrary, why dont dont we support it from the callee end like PSTN ?
If the callee is not at his seat, then why to hold up the resources until
caller's "Expire" header?
Think of the performance when there are millions of users hitting this bend
and blocking the resources for more than actually needed.
If I know that I am not available then I can configure my UAC somehow to
inform the caller on the very first ring that
I am not able to pick up the phone. I am just thinking it on the lines of
PSTN operation -- its not the caller who decides how long the call should be
presented
but its the callee's phone which handles it. If the current bis doesnt
support it then we might wanna bring in a minor extension to handle this.

Does it sound ok ?

Prabhas




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



From daemon@optimus.ietf.org  Fri May 10 14:02:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08703
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 14:02:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA03607
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 14:02:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02215;
	Fri, 10 May 2002 13:38:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02184
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 13:38:15 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07272
	for <sip@ietf.org>; Fri, 10 May 2002 13:38:06 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06242;
	Fri, 10 May 2002 13:37:42 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22669;
	Fri, 10 May 2002 13:37:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <J79SW0G7>; Fri, 10 May 2002 13:37:43 -0400
Message-ID: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Prabhas Sinha'" <prsinha@unity.ncsu.edu>,
        Bert Culpepper
	 <bert.culpepper@intervoice-brite.com>, sip@ietf.org
Subject: RE: [Sip] UPDATE and Expires
Date: Fri, 10 May 2002 13:37:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Pick up your phone and dial a number without a message system.
It will ring quite a while (not forever).  Mine waits multiple minutes.
The problem with making assumptions on how long to time out is 
that it's the user, not the UAC, that knows how long is long enough.  
What do you want to do, have him type in a timer length?  
Yes, you can use a timer on either end, but it needs to be on the 
order of minutes, not seconds, and it does not express the wishes 
of either the caller or the callee.  It's the system designer (or 
administrator if it's programmable)'s idea of how long is enough.

Note that in SIP, there are no messages passing while you are
waiting.  Of course, I want there to be a few (UPDATE with
Expire), just so that the called party knows the calling party
still thinks it ought to be ringing.  Then the expiry can be
on the order of seconds.

Brian

> -----Original Message-----
> From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu]
> Sent: Friday, May 10, 2002 1:06 PM
> To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org
> Subject: Re: [Sip] UPDATE and Expires
> 
> 
> > I would think the caller will have an idea of how long 
> he/she wants to
> wait
> > for answer, and set the value of the Expires header 
> accordingly in the
> > INVITE request.  However, if the caller's UA doesn't 
> support this and it
> > crashes, then I believe it's an implementation issue for 
> the UAS.  Or when
> > the callee answers the call, current defined protocol 
> behavior (no ACK
> > received) will suffice here.
> >
> > Regards,
> > Bert
> >
> 
> on the contrary, why dont dont we support it from the callee 
> end like PSTN ?
> If the callee is not at his seat, then why to hold up the 
> resources until
> caller's "Expire" header?
> Think of the performance when there are millions of users 
> hitting this bend
> and blocking the resources for more than actually needed.
> If I know that I am not available then I can configure my UAC 
> somehow to
> inform the caller on the very first ring that
> I am not able to pick up the phone. I am just thinking it on 
> the lines of
> PSTN operation -- its not the caller who decides how long the 
> call should be
> presented
> but its the callee's phone which handles it. If the current bis doesnt
> support it then we might wanna bring in a minor extension to 
> handle this.
> 
> Does it sound ok ?
> 
> Prabhas
> 
> 
> 

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



From daemon@optimus.ietf.org  Fri May 10 14:46:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11442
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 14:46:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA05698
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 14:46:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04725;
	Fri, 10 May 2002 14:27:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04170
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 14:14:53 -0400 (EDT)
Received: from dnvrpop4.dnvr.uswest.net (dnvrpop4.dnvr.uswest.net [206.196.128.6])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09498
	for <sip@ietf.org>; Fri, 10 May 2002 14:14:43 -0400 (EDT)
Received: (qmail 46681 invoked by uid 0); 10 May 2002 18:14:47 -0000
Received: from unknown (HELO MAYUSKO) (64.19.189.253)
  by dnvrpop4.dnvr.uswest.net with SMTP; 10 May 2002 18:14:47 -0000
Date: Fri, 10 May 2002 14:14:46 -0400
Message-ID: <000001c1f84e$91ac4bd0$30330a0a@MAYUSKO>
From: "Mark J. Yusko" <myusko@qwest.net>
To: sip-admin@ietf.org, "'Prabhas Sinha'" <prsinha@unity.ncsu.edu>,
        "'Bert Culpepper'" <bert.culpepper@intervoice-brite.com>, sip@ietf.org
Reply-To: <myusko@qwest.net>
Subject: RE: [Sip] UPDATE and Expires
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA04171
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] 
> Sent: Friday, May 10, 2002 1:38 PM
> To: 'Prabhas Sinha'; Bert Culpepper; sip@ietf.org
> Subject: RE: [Sip] UPDATE and Expires
> 
> Pick up your phone and dial a number without
> a message system.
> It will ring quite a while (not forever).  Mine
> waits multiple minutes.

I believe some class 4 switches (AT&T) have a 2 minute timeout for
ringing.  With 1 ring = 6 seconds, that's 20 rings.

> The problem with making assumptions on how long to
> time out is that it's the user, not the UAC, that
> knows how long is long enough.  
> What do you want to do, have him type in a timer
> length?  
> Yes, you can use a timer on either end, but it needs
> to be on the order of minutes, not seconds, and it
> does not express the wishes of either the caller or > the callee.
It's the system designer (or 
> administrator if it's programmable)'s idea of how
> long is enough.
>
> Note that in SIP, there are no messages passing
> while you are waiting.  Of course, I want there to
> be a few (UPDATE with Expire), just so that the
> called party knows the calling party still thinks it > ought to be
ringing.  Then the expiry can be on the > order of seconds.
>
> Brian
>
> -----Original Message-----
> From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu]
> Sent: Friday, May 10, 2002 1:06 PM
> To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org
> Subject: Re: [Sip] UPDATE and Expires
> 
> 
> > I would think the caller will have an idea of how long 
> he/she wants to
> wait
> > for answer, and set the value of the Expires header 
> accordingly in the
> > INVITE request.  However, if the caller's UA doesn't 
> support this and it
> > crashes, then I believe it's an implementation issue for 
> the UAS.  Or when
> > the callee answers the call, current defined protocol 
> behavior (no ACK
> > received) will suffice here.
> >
> > Regards,
> > Bert
> >
> 
> on the contrary, why dont dont we support it from the callee 
> end like PSTN ?
> If the callee is not at his seat, then why to hold up the 
> resources until
> caller's "Expire" header?
> Think of the performance when there are millions of users 
> hitting this bend
> and blocking the resources for more than actually needed.
> If I know that I am not available then I can configure my UAC 
> somehow to
> inform the caller on the very first ring that
> I am not able to pick up the phone. I am just thinking it on 
> the lines of
> PSTN operation -- its not the caller who decides how long the 
> call should be
> presented
> but its the callee's phone which handles it. If the current bis doesnt
> support it then we might wanna bring in a minor extension to 
> handle this.
> 
> Does it sound ok ?
> 
> Prabhas
> 
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 14:46:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11460
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 14:46:51 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA05745
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 14:47:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04708;
	Fri, 10 May 2002 14:27:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04673
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 14:27:35 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10270
	for <sip@ietf.org>; Fri, 10 May 2002 14:27:25 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4AIR3x01579
	for <sip@ietf.org>; Fri, 10 May 2002 14:27:03 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <KTF9K9MX>; Fri, 10 May 2002 19:27:02 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB00439E9D9@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Bob Penfield'"
	 <bpenfield@acmepacket.com>,
        "'Miguel A. Garcia'"
	 <Miguel.A.Garcia@ericsson.com>
Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR, sip@ietf.org, bernhard.honeisen@nokia.com
Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05
Date: Fri, 10 May 2002 19:27:00 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

The only issue I can think of would concern any responsibility or not for sorting out the best order of visiting this UA inserted proxy versus any others.

If I follow the current procedures, then any UA inserted URL would be the last proxy visited on any incoming dialog to the UA. This would be after visiting any proxy inserted URLs. If this meets Bob's requirements then fine, but I do not want to see any proxy requirement or registrar requirement for reordering the Path list.

Keith

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 07 May 2002 19:07
> To: 'Bob Penfield'; 'Miguel A. Garcia'
> Cc: 3GPP_TSG_CN_WG1@LIST.ETSI.FR; sip@ietf.org;
> bernhard.honeisen@nokia.com
> Subject: RE: [Sip] Re: WGLC for draft-willis-sip-path-05
> 
> 
> Bob asked:
> > A prior e-mail said that a UA was not allowed include a Path 
> > header. Is there a particular reason we want to prohibit the 
> > UA from contributing to the path? I can't think of a 
> > particular example, but a UA could know that a specific 
> > element needs to be on the inbound path, and that element may 
> > not be in the register path (just like a proxy adding "a Path 
> > element referencing another node" as described in section 4.2).
> 
> That's a reasonable question. It's not consistent with the original
> intent, but on first analysis, I can't think of a real reason 
> that this
> COULDN'T be done. Anybody else out there have an opinion?
> 
> >
Remainder snipped as not relevant to this issue.

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



From daemon@optimus.ietf.org  Fri May 10 15:16:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13045
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 15:16:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA06845
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 15:16:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05919;
	Fri, 10 May 2002 14:52:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05880
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 14:52:11 -0400 (EDT)
Received: from webmail10.rediffmail.com (webmail10.rediffmail.com [202.54.124.179] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11698
	for <sip@ietf.org>; Fri, 10 May 2002 14:52:01 -0400 (EDT)
Received: (qmail 10931 invoked by uid 510); 10 May 2002 18:52:12 -0000
Date: 10 May 2002 18:52:12 -0000
Message-ID: <20020510185212.10930.qmail@webmail10.rediffmail.com>
Received: from unknown (130.245.6.29) by rediffmail.com via HTTP; 10 May 2002 18:52:12 -0000
MIME-Version: 1.0
From: "nitin  khosla" <guy_need_love@rediffmail.com>
Reply-To: "nitin  khosla" <guy_need_love@rediffmail.com>
To: sip@ietf.org
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Subject: [Sip] SIP transaction machine problem...
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hello everybody,
   I have mailed so many times but nobody seems to reply.
I am a student and trying to verify SIP protocol. I started with 
transaction machines and then moving upward. I had some problems 
regarding the functioning of the same......

what happens  if:

a) Timer B fires and client goes in termination state.
   Server is in completed state retransmitting
response.
  Now till now client could not recieve any of
responses but just after it(client) terminates, one
response reaches client from the server (3xx). What
will client do then.
  It is not specified there in transaction machine.

b) One BIGGER problem , what if client is in
proceeding state and seerver terminates due to timer
H.
It just hangs because client keeps on waiting for
final response. THERE is NO timeout in client's
proceeding state. So  it seemed to me a bug.

I hope somebody do reply for my problem so that I could model it 
correctly because nothing is written about it in either INVITE 
Client - INVITE server transaction machines as far as i know. If 
it's written please refer me the place too.....

thanks
nitin



_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or 
Abroad
http://monsterindia.rediff.com/jobs


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



From daemon@optimus.ietf.org  Fri May 10 16:16:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15524
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 16:16:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA10640
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 16:16:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09770;
	Fri, 10 May 2002 16:01:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09723
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 16:01:05 -0400 (EDT)
Received: from crash.dfw.dynamicsoft.com ([63.110.3.64])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14984
	for <sip@ietf.org>; Fri, 10 May 2002 16:00:55 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4AK4VV01769;
	Fri, 10 May 2002 15:04:31 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip@ietf.org, Jon Peterson <jon.peterson@neustar.biz>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 10 May 2002 14:58:23 -0500
Message-Id: <1021060703.2011.235.camel@dhcp152.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Sip] Comment on sip-identity-00
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Paragraph 2 of 4.2 binds the username part of
credentials (such as DIGEST credentials) to an
identity represented as a SIP URI by algorithmically
placing that username into the user portion of the URI.

This instead should be policy at the authentication
service. That service knows how to bind whatever
credentials it was given to an identity. Presumably,
since it is a SIP identity service, it knows how to
express that identity as a SIP URI.

Using the algorithm suggested will create problems
for existing realms where the username "alice" is
owned by someone other than the person who owns
"alice@atlanta.com". It also wouldn't work for 
other credentialing methods where the analog of
username isn't syntactically valid for the user 
portion of a SIP URI.

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 daemon@optimus.ietf.org  Fri May 10 16:17:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15559
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 16:17:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA10716
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 16:17:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09910;
	Fri, 10 May 2002 16:01:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09878
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 16:01:31 -0400 (EDT)
Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15002
	for <sip@ietf.org>; Fri, 10 May 2002 16:01:17 -0400 (EDT)
Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116])
	by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4AK1PN03734;
	Fri, 10 May 2002 16:01:25 -0400 (EDT)
Message-ID: <048201c1f85d$76ffff20$743c0198@ecew2k.ncsu.edu>
From: "Prabhas Sinha" <prsinha@unity.ncsu.edu>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "Bert Culpepper" <bert.culpepper@intervoice-brite.com>, <sip@ietf.org>
References: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com>
Subject: Re: [Sip] UPDATE and Expires
Date: Fri, 10 May 2002 16:01:25 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I am not sure if Tom's reply reached all, just sending it for your
information.

----- Original Message -----
From: <Tom_Gray@Mitel.COM>
To: <Tom_Gray@Mitel.COM>
Cc: "Prabhas Sinha" <prsinha@unity.ncsu.edu>
Sent: Friday, May 10, 2002 1:13 PM
Subject: Re: [Sip] UPDATE and Expires


>
> CPL provides the functionality that you recommend. Calls can be declined
with
> reasons given either to everyone or to specific individuals
>
>

----- Original Message -----
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Prabhas Sinha'" <prsinha@unity.ncsu.edu>; "Bert Culpepper"
<bert.culpepper@intervoice-brite.com>; <sip@ietf.org>
Sent: Friday, May 10, 2002 1:37 PM
Subject: RE: [Sip] UPDATE and Expires


> Pick up your phone and dial a number without a message system.
> It will ring quite a while (not forever).  Mine waits multiple minutes.
> The problem with making assumptions on how long to time out is
> that it's the user, not the UAC, that knows how long is long enough.
> What do you want to do, have him type in a timer length?
> Yes, you can use a timer on either end, but it needs to be on the
> order of minutes, not seconds, and it does not express the wishes
> of either the caller or the callee.  It's the system designer (or
> administrator if it's programmable)'s idea of how long is enough.
>
> Note that in SIP, there are no messages passing while you are
> waiting.  Of course, I want there to be a few (UPDATE with
> Expire), just so that the called party knows the calling party
> still thinks it ought to be ringing.  Then the expiry can be
> on the order of seconds.
>
> Brian
>
> > -----Original Message-----
> > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu]
> > Sent: Friday, May 10, 2002 1:06 PM
> > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org
> > Subject: Re: [Sip] UPDATE and Expires
> >
> >
> > > I would think the caller will have an idea of how long
> > he/she wants to
> > wait
> > > for answer, and set the value of the Expires header
> > accordingly in the
> > > INVITE request.  However, if the caller's UA doesn't
> > support this and it
> > > crashes, then I believe it's an implementation issue for
> > the UAS.  Or when
> > > the callee answers the call, current defined protocol
> > behavior (no ACK
> > > received) will suffice here.
> > >
> > > Regards,
> > > Bert
> > >
> >
> > on the contrary, why dont dont we support it from the callee
> > end like PSTN ?
> > If the callee is not at his seat, then why to hold up the
> > resources until
> > caller's "Expire" header?
> > Think of the performance when there are millions of users
> > hitting this bend
> > and blocking the resources for more than actually needed.
> > If I know that I am not available then I can configure my UAC
> > somehow to
> > inform the caller on the very first ring that
> > I am not able to pick up the phone. I am just thinking it on
> > the lines of
> > PSTN operation -- its not the caller who decides how long the
> > call should be
> > presented
> > but its the callee's phone which handles it. If the current bis doesnt
> > support it then we might wanna bring in a minor extension to
> > handle this.
> >
> > Does it sound ok ?
> >
> > Prabhas
> >
> >
> >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 16:20:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15658
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 16:20:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA10845
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 16:20:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10305;
	Fri, 10 May 2002 16:07:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10274
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 16:07:25 -0400 (EDT)
Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15256
	for <sip@ietf.org>; Fri, 10 May 2002 16:07:15 -0400 (EDT)
Received: from ganga ([12.217.176.37]) by sccmmhc01.mchsi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP
          id <20020510200649.OTXV1219.sccmmhc01.mchsi.com@ganga>
          for <sip@ietf.org>; Fri, 10 May 2002 20:06:49 +0000
From: "P. Vijay" <pvijay@mchsi.com>
To: <sip@ietf.org>
Subject: RE: [Sip] UPDATE and Expires
Date: Fri, 10 May 2002 15:06:47 -0500
Message-ID: <000801c1f85e$378ebc40$6601a8c0@mchsi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <313680C9A886D511A06000204840E1CF030B52E9@whq-msgusr-02.pit.comms.marconi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

	I think the solution is either a policy decision implemented at the SIP
service provider level or a basic addition to the
INVITE/TRYING/RINGING/OK/ACK message flow.  I am for using INVITE expires
and letting the SP decide on (a) using its internal timer or expires,
whichever is lesser and (b) resetting the timer when it receives an UPDATE.
The call is cleared when the timer expires. This is based on reasons given
below.

	In the traditional telehpony world, answer timers (the time between start
of ringing and a valid answer) are (typically) set to avoid holding up
bandwidth for unbillable calls.  This is especially true for inband
signalling.  Even for out-of-band signaling, ISDN/ISUP, etc., the protocol
DEFINES timers between the state when the called party acknowledges (180)
the call (INVITE) and the state when a valid answer (200)is received.  If
the timer expires, then the call is cleared by the caller.  In reality, the
call is cleared by the switch that handles the caller's CPE (even that is a
gross simplification, but it will do).  In fact, the tandems with the lowest
configured answer timers clear the call and propagate the clearing in both
directions.  The important point here is that this behaviour is a
codification of what is seen as good policy (i.e, don't waste resources,
etc.), not necessarily essential for call control.

	In this case, the problem arose because the caller (UAC) died after sending
INVITE and UAS did not detect the client death.  Can that not be handled at
the trasport (tcp timers, heartbeats, etc.) and clear the call?

	In the case where the UAC is alive and keeps waiting for the 200, either
UAS or the called (UAS/UAC) could clear the call as described above.

	I have seen answer timers cause problems in regular telephony services, so
putting in mandatory timers (a-la ISDN or ISUP) would be a hindrance.
However, SP's need policies, preferably encoded in RFC's, that allow for
both call terminations on ring-no-answer and possibly extending the timer
(e.g. via UPDATE).

	SIP does not have to codify an answer timer, although it may be a good idea
to do provide some guidance.  Also, the timer can be exchanged in SDP,
except it would need to be sent in TRYING or RINGING. In the absence of a
timer, the matter of detecting a crashed device needs to addressed.

--Vijay--

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
> Of Rosen,
> Brian
> Sent: Friday, May 10, 2002 12:38 PM
> To: 'Prabhas Sinha'; Bert Culpepper; sip@ietf.org
> Subject: RE: [Sip] UPDATE and Expires
>
>
> Pick up your phone and dial a number without a message system.
> It will ring quite a while (not forever).  Mine waits
> multiple minutes.
> The problem with making assumptions on how long to time out is
> that it's the user, not the UAC, that knows how long is long enough.
> What do you want to do, have him type in a timer length?
> Yes, you can use a timer on either end, but it needs to be on the
> order of minutes, not seconds, and it does not express the wishes
> of either the caller or the callee.  It's the system designer (or
> administrator if it's programmable)'s idea of how long is enough.
>
> Note that in SIP, there are no messages passing while you are
> waiting.  Of course, I want there to be a few (UPDATE with
> Expire), just so that the called party knows the calling party
> still thinks it ought to be ringing.  Then the expiry can be
> on the order of seconds.
>
> Brian
>
> > -----Original Message-----
> > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu]
> > Sent: Friday, May 10, 2002 1:06 PM
> > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org
> > Subject: Re: [Sip] UPDATE and Expires
> >
> >
> > > I would think the caller will have an idea of how long
> > he/she wants to
> > wait
> > > for answer, and set the value of the Expires header
> > accordingly in the
> > > INVITE request.  However, if the caller's UA doesn't
> > support this and it
> > > crashes, then I believe it's an implementation issue for
> > the UAS.  Or when
> > > the callee answers the call, current defined protocol
> > behavior (no ACK
> > > received) will suffice here.
> > >
> > > Regards,
> > > Bert
> > >
> >
> > on the contrary, why dont dont we support it from the callee
> > end like PSTN ?
> > If the callee is not at his seat, then why to hold up the
> > resources until
> > caller's "Expire" header?
> > Think of the performance when there are millions of users
> > hitting this bend
> > and blocking the resources for more than actually needed.
> > If I know that I am not available then I can configure my UAC
> > somehow to
> > inform the caller on the very first ring that
> > I am not able to pick up the phone. I am just thinking it on
> > the lines of
> > PSTN operation -- its not the caller who decides how long the
> > call should be
> > presented
> > but its the callee's phone which handles it. If the current
> bis doesnt
> > support it then we might wanna bring in a minor extension to
> > handle this.
> >
> > Does it sound ok ?
> >
> > Prabhas
> >
> >
> >
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 10 17:01:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17500
	for <sip-archive@odin.ietf.org>; Fri, 10 May 2002 17:01:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA13712
	for sip-archive@odin.ietf.org; Fri, 10 May 2002 17:01:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11931;
	Fri, 10 May 2002 16:37:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11900
	for <sip@optimus.ietf.org>; Fri, 10 May 2002 16:37:23 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16266
	for <sip@ietf.org>; Fri, 10 May 2002 16:37:12 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id AF81304E0254; Fri, 10 May 2002 16:37:21 -0400
Message-ID: <007301c1f862$a79926c0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <duncan.mills@vf.vodafone.co.uk>, <sip@ietf.org>
References: <DDC3D921FB67D211AAD100A0C9E58F530B2CA0DF@hampstead.vfl.vodafone>
Subject: Re: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt
Date: Fri, 10 May 2002 16:38:34 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

1) The examples given in section 4 (a laptop in an airport or hotel) do not
sound like access networks that will provide the "transitive trust" required
to protect privacy as described in section 6. Are these really valid
examples for usage of this header? Or are you assuming that this would only
work for local ISPs and airports that had a business relationship with the
home network? How does the UA know if these types of access networks can be
trusted?

2) Does this draft need an explicit Applicability Statement?

3) Section 6 says:

    The serving proxy MUST delete this header before
    forwarding the message outside of the its domain.

but section 7 says:

    A serving proxy, typically located in the home network, and therefore
    trusted, SHOULD delete the header when the SIP signaling is forwarded
    beyond the home network domain

and section 8 says:

    This header SHOULD always be deleted by the serving network prior to
    forwarding it outside of the home network domain, as described in
    section 7.

Is it MUST or SHOULD? Also, I think it is sufficient to have the MUST or
SHOULD once (in the Proxy behavior section) or maybe twice, and then say
"...serving proxies will delete..." in other places you need to talk about
it. I realize it is very important.

4) The document has weird characters where single quotes (i.e. ') should be.

5) You say "... where the access-type is æ3GPP-GERANÆ, the access-info
SHALL be "3GPP-CGI".", but go on to says the mapping of access-type to
access-info is defined elsewhere. Can you provide a reference? Also, I don't
think you should use the requirements language (SHALL) for an example like
this. If there are mapping requirement, they should all be included or you
should refer to a document that defines them.

6) The period is missing between 'request' and 'The' in section 7.1 "... SIP
message request The UAC SHOULD ..."

7) Section 7.1, 2nd paragraph. Should "the nature or the information" be
"the nature *of* the information"?

8) Section 7.2 is labeled "UAS behavior", but talks only about proxy
behavior. I don't think there is any UAS behavior for this header.

9) In section 7.2 you say the proxy "MAY use the contents to, e.g., provide
...". I suggest you remove the "e.g." and say something like "... MAY use
the contents to provide a different service or apply performance enhancement
measures depending on the network through which the UA is
accessing the server. For example, ....".

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: <duncan.mills@vf.vodafone.co.uk>
To: <sip@ietf.org>
Sent: Friday, May 10, 2002 8:38 AM
Subject: RE: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt


> All,
>
> The P-Access-Network-Info header draft (version 01) has been available for
> some time now, and I have received very few comments related to it.
>
> Does this mean there are no problems with the draft?
>
> Regards,
>
> Duncan
>
> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: 03 May 2002 12:28
> To: IETF-Announce
> Cc: sip@ietf.org
> Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title : The SIP Access Network Info header
> Author(s) : D. Mills
> Filename : draft-mills-sip-access-network-info-01.txt
> Pages : 5
> Date : 02-May-02
>
> This document defines the private SIP extension header
> P-Access-Network-Info. This mechanism is useful in SIP networks that
> are partitioned, such as 3G wireless networks which are partitioned at
> the SIP layer into 'access' and 'home' networks. SIP User Agents may
> use this header to relay information about the access network to
> serving proxies in their home network. The serving proxy may then use
> this information to optimize services for the UA. For example, a 3GPP
> terminal uses this header to pass information about the access network
> such as radio access technology and cell ID to its home service.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-01.t
> xt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-mills-sip-access-network-info-01.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-mills-sip-access-network-info-01.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
>


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



From daemon@optimus.ietf.org  Sat May 11 02:33:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19232
	for <sip-archive@odin.ietf.org>; Sat, 11 May 2002 02:33:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA12511
	for sip-archive@odin.ietf.org; Sat, 11 May 2002 02:33:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11108;
	Sat, 11 May 2002 01:49:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA11083
	for <sip@optimus.ietf.org>; Sat, 11 May 2002 01:49:14 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09872
	for <sip@ietf.org>; Sat, 11 May 2002 01:49:03 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 176PkX-0001Ei-00; Sat, 11 May 2002 08:48:57 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15580.45257.417255.716250@harjus.eng.song.fi>
Date: Sat, 11 May 2002 08:48:57 +0300
To: Robert Sparks <rsparks@dynamicsoft.com>
Cc: sip@ietf.org, Jon Peterson <jon.peterson@neustar.biz>
Subject: [Sip] Comment on sip-identity-00
In-Reply-To: <1021060703.2011.235.camel@dhcp152.dfw.dynamicsoft.com>
References: <1021060703.2011.235.camel@dhcp152.dfw.dynamicsoft.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

there seems to be lots of confusion about what "authenticated identity"
of a sip user is.  in our network it is simply the Network Access
Identity (NAI) of the user, e.g., foo@bar.com.  that same NAI is used
for all services the user has subscribed to, e.g., email, remote access,
and sip, and thus is not sip specific.

the NAI does necessarily have NOTHING to do with the sip uri that the
user registers and want to be known by.  for example, the user with NAI
foo@bar.com may want to register a sip uri sip:+358333983900@bar.com or
several sip uris of that or other sort.  the user specifically may NOT
want to register as sip:foo@bar.com.

my conclusion of all this is that the authentication server must verify
both the NAI of the user and the sip uri of the user that the user has
placed in the from header or, in case of an anonymous call, in some
other header of the message.  it seems to me that for the other parties
to which the message is forwarded to, it is enough that the
authenticated sip uri is included in the message.

regarding the i-d on the subject line, the distinction between the NAI
and sip uris of the user should be clarified before we can go on.

-- 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 daemon@optimus.ietf.org  Mon May 13 04:36:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00686
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 04:36:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA17518
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 04:36:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15793;
	Mon, 13 May 2002 04:13:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15762
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 04:13:01 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00243
	for <sip@ietf.org>; Mon, 13 May 2002 04:12:50 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4D8Cw0E025308;
	Mon, 13 May 2002 10:12:58 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4D8Cv9q024756;
	Mon, 13 May 2002 11:12:57 +0300 (EET DST)
Message-ID: <3CDF7583.CF7745A7@lmf.ericsson.se>
Date: Mon, 13 May 2002 11:12:51 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
CC: vishal <vishal@knowsys.net>, sip@ietf.org
Subject: Re: [Sip] Header comparision
References: <006c01c1f7f4$900df800$5101a8c0@knowsys.net> <013b01c1f7f5$9ed51f20$5401a8c0@knowsys.net> <3CDB7F62.7DE4B42C@lmf.ericsson.se> <00c001c1f7ff$fa3b5c80$5601a8c0@knowsys.net> <3CDB905B.4CA150B7@lmf.ericsson.se> <001101c1f805$4a4d7640$5601a8c0@knowsys.net> <3CDB9C61.3FF7FC4F@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Christer,

as you have pointed out, the comparison rules for To and From header
felds are not properly defined in bis. You have to perform URI
comparison. Therefore, user names and angle brakets do not affect the
comparison. This will be clarified in subsequent versions of the spec.

Regards,

Gonzalo



Christer Holmberg wrote:
> 
> Hi,
> 
> > Hi christer ,
> >    I am trying to say that ....YES IT REALLY MATTERS ,if From field does not
> > exactly matches then it is an error .Another question is ....why UAS will
> > add angular brackets  ...and why UAC will further check different syntax
> > available after receiving message sent by UAS??
> >
> > best solution is to compare From field as was sent in initial request .
> 
> Yes, you can do a pure binary comparision, but that also requires the order the
> uri parameters are the same, there is no case difference etc.
> 
> Why I would want to do this or that (I didn't even said I would) really doesn't
> matter. I am just trying to get a clarification on the angle bracket case, the
> uri parameter order case, and the case sensitivity case, for header mapping
> within a transaction...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> >
> >
> > regards, vishal
> >
> > ----- Original Message -----
> > From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
> > To: vishal <vishal@knowsys.net>
> > Cc: Madhusudhan <madhusudhan@knowsys.net>; <sip@ietf.org>
> > Sent: Friday, May 10, 2002 2:48 PM
> > Subject: Re: [Sip] Header comparision
> >
> > >
> > > Hi,
> > >
> > > I know what chapter 8.2.6.2 says, but my question was if it really also
> > affects
> > > the angle brackets.
> > >
> > > Another related issue: chapter 19.1.4 says that the uri parameter ordering
> > is
> > > not significant for URI comparision, but according to chapter 8.2.6.2 the
> > uri
> > > parameter ordering would have to match in a request/response transaction.
> > >
> > > Also, from a URI comparision point of view, some parts of the URI are
> > > case-insensitive. But, does it mean that within a transaction everything
> > is
> > > case-sensitive?
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > >
> > >
> > > vishal wrote:
> > >
> > > > Hi christer,
> > > >     From,To,Call-Id ,Cseq fields of sip response MUST exactly match
> > > > corresponding request.If it does not match exactly ,then it should be
> > > > protocol error .
> > > >
> > > > Reason:
> > > >    you dont require addition checking while copying these fields .
> > > >
> > > > case you described ,
> > > > To: el.sipo@sipworld.sip and
> > > > To: <el.sipo@sipworld.sip>  are equivalent ,not equal.
> > > >
> > > > please refer to sip bis 09  section 8.2.6.2 below
> > > >
> > > > "8.2.6.2 Headers and Tags
> > > >
> > > >    The From field of the response MUST equal the From header field of
> > > >    the request. The Call-ID header field of the response MUST equal the
> > > >    Call-ID header field of the request. The CSeq header field of the
> > > >    response MUST equal the CSeq field of the request. The Via header
> > > >    field values in the response MUST equal the Via header field values
> > > >    in the request and MUST maintain the same ordering.
> > > >
> > > >    If a request contained a To tag in the request, the To header field
> > > >    in the response MUST equal that of the request. However, if the To
> > > >    header field in the request did not contain a tag, the URI in the To
> > > >    header field in the response MUST equal the URI in the To header
> > > >    field; additionally, the UAS MUST add a tag to the To header field in
> > > >    the response (with the exception of the 100 (Trying) response, in
> > > >    which a tag MAY be present)"
> > > >
> > > > regards, vishal
> > > >
> > > > ----- Original Message -----
> > > > From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
> > > > To: Madhusudhan <madhusudhan@knowsys.net>
> > > > Cc: <sip@ietf.org>
> > > > Sent: Friday, May 10, 2002 1:35 PM
> > > > Subject: Re: [Sip] Header comparision
> > > >
> > > > >
> > > > > Hi Madhusudhan,
> > > > >
> > > > > Thanks for your comments!
> > > > >
> > > > > However, I think we are talking about two separate issues.
> > > > >
> > > > > Yes, in some cases (as mentioned) the URI MUST be enclosed in angle
> > > > brackets,
> > > > > but that does NOT mean you aren't allowed to enclose the URI in angle
> > > > brackets
> > > > > ALSO in other cases. For example:
> > > > >
> > > > > To: <sip:el.sipo@sipworld.com>
> > > > >
> > > > > ...is allowed from a SIP syntax point of view.
> > > > >
> > > > > However, my question was related to the COMPARISION of headers.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > >
> > > > > Madhusudhan wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > Section 20 of bis09 mentions
> > > > > >
> > > > > >   "The Contact, From, and To header fields contain a URI. If the URI
> > > > > >    contains a comma, question mark or semicolon, the URI MUST be
> > > > > >    enclosed in angle brackets (< and >). Any URI parameters are
> > > > > >    contained within these brackets. If the URI is not enclosed in
> > angle
> > > > > >    brackets, any semicolon-delimited parameters are
> > header-parameters,
> > > > > >    not URI parameters"
> > > > > >
> > > > > >  From the above comments, I think it is evident that the two
> > addresses
> > > > are
> > > > > > different.
> > > > > >
> > > > > > correct me if I am wrong!!!
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Madhusudhan
> > > > > >
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>
> > > > > > > To: <sip@ietf.org>
> > > > > > > Sent: Friday, May 10, 2002 12:11 PM
> > > > > > > Subject: [Sip] Header comparision
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I have a small clarification question on To- and From header
> > > > > > > > comparision.
> > > > > > > >
> > > > > > > > Chapter 8.2.6.2 says:
> > > > > > > >
> > > > > > > > "The From field of the response MUST equal the From header field
> > of
> > > > > > > > the request."
> > > > > > > >
> > > > > > > > Later in the chapter it explains the use of tags.
> > > > > > > >
> > > > > > > > However, there is nothing said (not in the URI comparision
> > chapter
> > > > > > > > either) about the "<" and ">" characters, so my question is:
> > > > > > > >
> > > > > > > > If the UAC doesn't include "<" and ">" in the request, and the
> > UAS
> > > > DOES
> > > > > > > > include them in the response, is it a protocol error?
> > > > > > > >
> > > > > > > > example:
> > > > > > > >
> > > > > > > > Request:
> > > > > > > >
> > > > > > > > To: el.sipo@sipworld.sip
> > > > > > > >
> > > > > > > > Response:
> > > > > > > >
> > > > > > > > To: <el.sipo@sipworld.sip>
> > > > > > > >
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Christer Holmberg
> > > > > > > > Ericsson Finland
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > > > > > This list is for NEW development of the core SIP 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

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@optimus.ietf.org  Mon May 13 05:27:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00684
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 04:36:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA17511
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 04:36:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15487;
	Mon, 13 May 2002 04:07:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA15451
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 04:06:50 -0400 (EDT)
Received: from hss.hns.com ([164.164.94.118])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00130
	for <sip@ietf.org>; Mon, 13 May 2002 04:06:37 -0400 (EDT)
From: sunayak@hss.hns.com
Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10])
	by hss.hns.com (8.11.6/8.11.2) with SMTP id g4D84MH20413
	for <sip@ietf.org>; Mon, 13 May 2002 13:34:24 +0530
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 65256BB8.002C8725 ; Mon, 13 May 2002 13:36:21 +0530
X-Lotus-FromDomain: HSSBLR
To: sip@ietf.org
Message-ID: <65256BB8.002C85D5.00@sampark.hss.hns.com>
Date: Mon, 13 May 2002 13:36:18 +0530
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [Sip] Clarity in ACK authentication
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org



Hi,
     Quoting bis-09 (Line 4860-4861) :
"UACs creating an ACK message will duplicate all of the
Authorization and Proxy-Authorization header field values
that appeared in the INVITE to which the ACK corresponds."

My interpretation of the above is (Correct me if i am wrong):
a. The method used to compute the response digest in the ACK
   request should be "INVITE" and not "ACK".
b. The nonce-count in the ACK should be the same as that
   of INVITE though it is a different request.

     In other words, is it that servers are not supposed to
treat such requests as replay attacks even though a previous
request arrived with the exact same nonce-count ? This is fine
in case of stateful proxies, but are stateless proxies also
expected to maintain such state information to determine whether
the ACK credentials are valid ?


Thanks in advance,
Subhash Nayak U.
Hughes Software Systems
http://www.hssworld.com







This message is proprietary to Hughes Software Systems Limited (HSS) 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.  HSS 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



From daemon@optimus.ietf.org  Mon May 13 12:45:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19264
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 12:45:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA13089
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 12:45:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11880;
	Mon, 13 May 2002 12:24:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11849
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 12:24:16 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18529
	for <sip@ietf.org>; Mon, 13 May 2002 12:24:03 -0400 (EDT)
From: Ignacio.Almar@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4DGN8Y20883
	for <sip@ietf.org>; Mon, 13 May 2002 19:23:09 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5ad7b276dbac158f25076@esvir05nok.ntc.nokia.com> for <sip@ietf.org>;
 Mon, 13 May 2002 19:24:13 +0300
Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Mon, 13 May 2002 19:24:13 +0300
Received: from maebe001.NOE.Nokia.com ([10.209.0.44]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Mon, 13 May 2002 19:24:13 +0300
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 13 May 2002 18:24:12 +0200
Message-ID: <05C8D36DA4EF684D8BD4E309B1CD5AF166DFC7@maebe001.NOE.Nokia.com>
Thread-Topic: Sending SOAP over SIP
Thread-Index: AcH6mpYY7FIHkWaUEdaaLQAAhlfbdw==
To: <sip@ietf.org>
X-OriginalArrivalTime: 13 May 2002 16:24:13.0681 (UTC) FILETIME=[9EA81E10:01C1FA9A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA11850
Subject: [Sip] Sending SOAP over SIP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

hi all,

	Thanks in advance. 

	To send SOAP over HTTP, the tag 'SOAPAction' is sent in the HTTP headers when sending SOAP requests to identify the intent of the request. This header can be used by the Firewalls and Proxies to filter the SOAP Message. In HTTP this field is defined as mandatory, so the client MUST include this field in the HTTP header when sending a SOAP message. SOAP can be sent over HTTP as a ContentType=text/xml, and over SIP with the same content type. 
	In SIP, to allow the appropiate filtering by proxies there should be defined a SOAPAction field as mandatory in the client request. Do you think if there is something defined regarding this ? 

	Another option to let the proxies identify that a SOAP message is inside the SIP message would be to define a ContentType=text/soap+xml, but I think that this is not defined currently in IANA.
	
	Note that I am trying to avoid the use of a proprietary format, but I am pointing a general format of sending SOAP over SIP. And also, I am referring to individual sessionless calls, including the SOAP code in a single SIP call, not using a SIP call to establish a session (INVITE) and afterwards send a message using HTTP. 

Br,
	Ignacio

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



From daemon@optimus.ietf.org  Mon May 13 14:47:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25869
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 14:47:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA18700
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 14:48:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17767;
	Mon, 13 May 2002 14:29:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17735
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 14:29:06 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24878
	for <sip@ietf.org>; Mon, 13 May 2002 14:28:52 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4DISXd10382;
	Mon, 13 May 2002 13:28:34 -0500
Message-ID: <031e01c1faab$feb9ddf0$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Dean Willis" <dean.willis@softarmor.com>, <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, "'Allison Mankin'" <mankin@isi.edu>,
        <brian.rosen@cisco.com>, <jo@ipdialog.com>, <rsparks@dynamicsoft.com>
Subject: Oops:  Closed: Re: [Sip] WGLC for Refer Draft
Date: Mon, 13 May 2002 13:28:35 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

ok, I'm a little slow, the final changes are reflected in -03, not -02.

--
Dean


----- Original Message -----
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Dean Willis" <dean.willis@softarmor.com>; <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>; "'Allison Mankin'"
<mankin@isi.edu>; <brian.rosen@cisco.com>; <jo@ipdialog.com>;
<rsparks@dynamicsoft.com>
Sent: Monday, May 13, 2002 1:23 PM
Subject: Closed: Re: [Sip] WGLC for Refer Draft


> Ok, we're moving this to IETF last call now.
>
> Working group comments were addressed and the document reissued as
> draft-ietf-sip-refer-02.
>
> --
> Dean
>
> ----- Original Message -----
> From: "Dean Willis" <dean.willis@softarmor.com>
> To: <sip@ietf.org>
> Cc: "'Rohan Mahy'" <rohan@cisco.com>; "'Allison Mankin'"
> <mankin@isi.edu>; <brian.rosen@cisco.com>; <jo@ipdialog.com>;
> <rsparks@dynamicsoft.com>
> Sent: Thursday, May 02, 2002 5:31 PM
> Subject: [Sip] WGLC for Refer Draft
>
>
> >
> > I'd like to request Working Group Last Call for the REFER method.
> >
> > The current version is availabe as:
> >
> >
>
http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-refer-split-00.tx
> > t
> >
> > Or
> >
> >
>
http://search.ietf.org/internet-drafts/draft-sparks-sip-refer-split-00.t
> > xt
> >
> >
> > We need to close this by app May 21, so get your comments in. Please
> > copy the list AND Rober tSparks, who will consolidate responses.
> >
> > --
> > 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 daemon@optimus.ietf.org  Mon May 13 14:52:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26113
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 14:52:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA18893
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 14:52:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17554;
	Mon, 13 May 2002 14:23:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17524
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 14:23:43 -0400 (EDT)
Received: from crash.dfw.dynamicsoft.com ([63.110.3.64])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24027
	for <sip@ietf.org>; Mon, 13 May 2002 14:23:26 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4DIR7V17230;
	Mon, 13 May 2002 13:27:07 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: Robert Sparks <rsparks@dynamicsoft.com>
Cc: "'Dean Willis'" <dwillis@dynamicsoft.com>, sip@ietf.org,
        Brian Rosen
	 <brian.rosen@marconi.com>, Joerg Ott <jo@ipdialog.com>
In-Reply-To: <1020818249.1320.53.camel@localhost.localdomain>
References: 
	<EF1056F8EB4ED511B8FB0002A56079D401E5B065@zrc2c014.us.nortel.com> 
	<1020818249.1320.53.camel@localhost.localdomain>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 13 May 2002 13:18:49 -0500
Message-Id: <1021313930.1227.3.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Sip] Ending WGLC SIP MIME Types Registration Draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

There has been only one comment on the MIME types registration
draft in the last ten days. As such, I would like to close last
call on this document and allow it to proceed to IETF last call.

The following change will be incorporated along with comments
from IETF last call.

RjS

On Tue, 2002-05-07 at 19:37, Robert Sparks wrote:
> Ok.
> 
> The right way to say this is to call to 
> section 7.4.1 of bis-09/rfc3261 for what is required
> if a body is present. I'll make that change.
> 
> RjS
> 
> On Tue, 2002-05-07 at 16:47, Sriram Parameswar wrote:
> > Hi: 
> > 
> > Quoting section 1 "If the message/sipfrag part contains a body, it must
> > also contain a Content-Length header and the null-line separating
> > headers from the body." 
> > 
> > I think it would be a good idea to include the Content-Type and possibly
> > other Content related headers (Content-Encoding, Content-Language etc.)
> > - as a SHOULD strength. I am not sure what good it would do, to get a
> > body without the requisite information to extract its true meaning.
> > 
> > Thanks, 
> > 
> > Sriram 
> > 
> > __________________________________________ 
> > Sriram Parameswar              Phone: 972-685-8540 
> > Interactive Multimedia Server (IMS) Fax: 972-684-3986 
> > Nortel Networks, Richardson USA  Email: sriramp@nortelnetworks.com 
> > 
> > 
> > -----Original Message----- 
> > From: Dean Willis [ mailto:dwillis@dynamicsoft.com
> > <mailto:dwillis@dynamicsoft.com> ] 
> > Sent: Thursday, May 02, 2002 5:32 PM 
> > To: sip@ietf.org 
> > Cc: 'Rohan Mahy'; brian.rosen@marconi.com; 'Allison Mankin'; 
> > jo@ipdialog.com; rsparks@dynamicsoft.com 
> > Subject: [Sip] WGLC SIP MME Types Registration Draft 
> > 
> > 
> > I'd like to request WGLC of the SIP MIME type registration draft. 
> > 
> > The current version can be found at: 
> > 
> > http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt
> > <http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-mimetypes-03.txt
> > >  
> > 
> > Or 
> > 
> > http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt
> > <http://search.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.tx
> > t>  
> > 
> > 
> > 
> > We'd like to close WGLC by about May 21. 
> > 
> > Please copy comments to the list and to Robert Sparks, who will 
> > coordinate further efforts. 
> > 
> > -- 
> > Dean 
> > 
> > 
> > 
> > _______________________________________________ 
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > <https://www1.ietf.org/mailman/listinfo/sip>  
> > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Mon May 13 15:35:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28503
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 15:35:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA21482
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 15:36:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20399;
	Mon, 13 May 2002 15:16:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20370
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 15:16:42 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27407
	for <sip@ietf.org>; Mon, 13 May 2002 15:16:28 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4DJGbX11506;
	Mon, 13 May 2002 14:16:37 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Sip" <sip@ietf.org>, "Simple" <simple@mailman.dynamicsoft.com>
Cc: "Robert Sparks" <rsparks@dynamicsoft.com>,
        "Jon Peterson" <jon.peterson@neustar.biz>,
        "Dean Willis" <dwillis@dynamicsoft.com>,
        "Brian. Rosen@Marconi. Com" <brian.rosen@marconi.com>,
        "Jo@Ipdialog. Com" <jo@ipdialog.com>
Date: Mon, 13 May 2002 14:16:26 -0500
Message-ID: <HNEOJECGFHIABDLENMMCCEHJCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Message draft changes
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,

I submitted draft-ietf-sip-message-04 last week. This version contains a few
AD requested changes, primarily in the area of congestion control.
Specifically:

1) Added an applicability statement clarifying the difference between the
pager and session models, and that this draft only defines the pager model.

2) Strengthened the congestion control section:

   * 1300 byte hard limit for physical payload size for pager model. This
applies to the actual payload only, not indirect content. Fragmenting
content across multiple requests is prohibited for pager model.

   * Overlapping MESSAGE requests outside of dialog but to same request-URI
are prohibited.
   * Overlapping MESSAGE requests inside a dialog are prohibited unless
every hop of the dialog uses a congestion-controlled transport, in which
case the strength is SHOULD NOT.

3) Trimmed the author list and added contributor section.

I do not believe we need to do another WGLC for these changes. Any new
feedback to 04 can be captured as part of the IETF last call.

The draft is available at:

http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt

Thanks!

Ben.



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



From daemon@optimus.ietf.org  Mon May 13 16:21:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01031
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 16:21:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA23840
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 16:21:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22820;
	Mon, 13 May 2002 16:04:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA22772
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 16:04:42 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29936
	for <sip@ietf.org>; Mon, 13 May 2002 16:04:28 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DK4B816872;
	Mon, 13 May 2002 15:04:11 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXXQMCD>; Mon, 13 May 2002 15:04:46 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B076@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: "'rohan@cisco.com'" <rohan@cisco.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Date: Mon, 13 May 2002 15:04:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FAB9.62FC4C00"
Subject: [Sip] Comments :draft-ietf-sip-replaces-01.txt (Re-post)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1FAB9.62FC4C00
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,

I had sent these comments prior to the Las Vegas Ad-Hoc, have not seen any
of discussion on this draft on the list. Just re-posting one more time.

Regards,

Sriram

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Nortel Networks

Rohan,

Some comments:

(1)Section 4.1 says "In other words the to-tag is compared to the local tag,
and the from-tag is compared to the remote tag." However in section 5.2
INV/200 estalish from-tag (operator) = 7743 and to-tag (Call Center) = 6472.
However the call from the customer to Call Center has
Replaces:425928@dhcp23311.acme.com;to-tag=7743;from-tag=6472, thus the Call
Center will _not_ be able to match correctly based on sections 4.1 rule.

(2) Section 5.2 the NOTIFY sent to from Customer to Operator when the
Customer receives 182 (Queued). Then this transaction is BYE'd. Now we
_cannot_ send another NOTIFY/200 from Customer to Operator as shown - it
will result in a 481.

(3) Same for section 5.7 (and section 5.8) - once Bob gets a 687, he BYE's
the call with Alice. Then at the bottom of call Flow, Alice tries to send a
NOTIFY for the REFER, this will result in a 481.

(3) Section 5.8 Invite from Proxy (forking Alice) INVITE (2a) and (2b) goes
to C1. I think INVITE (2b) should go to C2.

(4) Section 5.6, just for grins, how does Alice get the Replaces information
to replace the dialog between Bob and Old Timer :).

Thats what I have from my initial reading.

Sriram 

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

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Comments :draft-ietf-sip-replaces-01.txt (Re-post)</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>I had sent these comments prior to the Las Vegas =
Ad-Hoc, have not seen any of discussion on this draft on the list. Just =
re-posting one more time.</FONT></P>

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

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

<P><FONT SIZE=3D2>__________________________________________</FONT>
<BR><FONT SIZE=3D2>Sriram =
Parameswar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; Phone: 972-685-8540</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
</P>

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

<P><FONT SIZE=3D2>Some comments:</FONT>
</P>

<P><FONT SIZE=3D2>(1)Section 4.1 says &quot;In other words the to-tag =
is compared to the local tag, and the from-tag is compared to the =
remote tag.&quot; However in section 5.2 INV/200 estalish from-tag =
(operator) =3D 7743 and to-tag (Call Center) =3D 6472. However the call =
from the customer to Call Center has =
Replaces:425928@dhcp23311.acme.com;to-tag=3D7743;from-tag=3D6472, thus =
the Call Center will _not_ be able to match correctly based on sections =
4.1 rule.</FONT></P>

<P><FONT SIZE=3D2>(2) Section 5.2 the NOTIFY sent to from Customer to =
Operator when the Customer receives 182 (Queued). Then this transaction =
is BYE'd. Now we _cannot_ send another NOTIFY/200 from Customer to =
Operator as shown - it will result in a 481.</FONT></P>

<P><FONT SIZE=3D2>(3) Same for section 5.7 (and section 5.8) - once Bob =
gets a 687, he BYE's the call with Alice. Then at the bottom of call =
Flow, Alice tries to send a NOTIFY for the REFER, this will result in a =
481.</FONT></P>

<P><FONT SIZE=3D2>(3) Section 5.8 Invite from Proxy (forking Alice) =
INVITE (2a) and (2b) goes to C1. I think INVITE (2b) should go to =
C2.</FONT>
</P>

<P><FONT SIZE=3D2>(4) Section 5.6, just for grins, how does Alice get =
the Replaces information to replace the dialog between Bob and Old =
Timer :).</FONT></P>

<P><FONT SIZE=3D2>Thats what I have from my initial reading.</FONT>
</P>

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

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

</BODY>
</HTML>
------_=_NextPart_001_01C1FAB9.62FC4C00--

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



From daemon@optimus.ietf.org  Mon May 13 19:52:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09828
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 19:52:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA04778
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 19:52:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04494;
	Mon, 13 May 2002 19:36:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA04453
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 19:35:52 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09431
	for <sip@ietf.org>; Mon, 13 May 2002 19:35:38 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4DNZId12166;
	Mon, 13 May 2002 18:35:18 -0500
Message-ID: <004c01c1fad6$da23d010$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>
Cc: "Bernhard Honeisen" <bernhard.honeisen@nokia.com>,
        "Brian Rosen" <Brian.Rosen@marconi.com>, <jo@ipdialog.com>,
        <mankin@isi.edu>
Date: Mon, 13 May 2002 18:35:22 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Revised draft: draft-willis-sip-path-06
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Bernie and I have revised the Path draft to account (I think) for all
comments received during WGLC.

The latest version is available at:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.html
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-06.xml

Note: Insertion of this draft into the internet-drafts list should be
announced to the SIP working group.

Note that one of the big changes was using the term "header field" to
refer to what is colloquially called a "header" and "header field value"
for an element that might go into a header field. There were also
significant enhancement to the security considerations section and
general editing to correct typos and use consistent terminology. Thanks
for all the feedback, folks.

--
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 daemon@optimus.ietf.org  Mon May 13 21:38:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13434
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 21:38:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA10391
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:38:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27147;
	Mon, 13 May 2002 07:49:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27105
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 07:49:02 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04391
	for <sip@ietf.org>; Mon, 13 May 2002 07:48:44 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DBmGt11274;
	Mon, 13 May 2002 13:48:16 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4DBlQX05613;
	Mon, 13 May 2002 12:47:30 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KVTH6XWW>; Mon, 13 May 2002 12:48:59 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F720C@zwcwd00r.europe.nortel.com>
From: "Mark Watson"<mwatson@nortelnetworks.com>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        Robert Sparks
	 <rsparks@dynamicsoft.com>
Cc: sip@ietf.org, Jon Peterson <jon.peterson@neustar.biz>
Subject: RE: [Sip] Comment on sip-identity-00
Date: Mon, 13 May 2002 12:48:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FA74.2543D5BC"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1FA74.2543D5BC
Content-Type: text/plain;
	charset="iso-8859-1"

Before we get too confused, 'Network Asserted Identity' - which we have been
discussing for some time and for which draft-ietf-sipping-nai-reqs-00
presents requirements, is a different and in principle unrelated topic from
Network Access Identifier in the AAA sense, despite sharing the same
acronym.

There may of course be local policies of Authentication Services which
relate these two, but this is of no importance to us here, which I think is
Juha's point below.

To avoid such confusion, it he been suggested that we do not use
Network-Asserted-Identity: as the header name. 'Asserted-Identity:' is
currently top of the poll. If you don't like this header name, 'speak now or
forever hold your peace'.

...Mark



> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 11 May 2002 06:49
> To: Robert Sparks
> Cc: sip@ietf.org; Jon Peterson
> Subject: [Sip] Comment on sip-identity-00
> 
> 
> there seems to be lots of confusion about what "authenticated 
> identity"
> of a sip user is.  in our network it is simply the Network Access
> Identity (NAI) of the user, e.g., foo@bar.com.  that same NAI is used
> for all services the user has subscribed to, e.g., email, 
> remote access,
> and sip, and thus is not sip specific.
> 
> the NAI does necessarily have NOTHING to do with the sip uri that the
> user registers and want to be known by.  for example, the 
> user with NAI
> foo@bar.com may want to register a sip uri 
> sip:+358333983900@bar.com or
> several sip uris of that or other sort.  the user specifically may NOT
> want to register as sip:foo@bar.com.
> 
> my conclusion of all this is that the authentication server 
> must verify
> both the NAI of the user and the sip uri of the user that the user has
> placed in the from header or, in case of an anonymous call, in some
> other header of the message.  it seems to me that for the 
> other parties
> to which the message is forwarded to, it is enough that the
> authenticated sip uri is included in the message.
> 
> regarding the i-d on the subject line, the distinction between the NAI
> and sip uris of the user should be clarified before we can go on.
> 
> -- 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
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Sip] Comment on sip-identity-00</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Before we get too confused, 'Network Asserted =
Identity' - which we have been discussing for some time and for which =
draft-ietf-sipping-nai-reqs-00 presents requirements, is a different =
and in principle unrelated topic from Network Access Identifier in the =
AAA sense, despite sharing the same acronym.</FONT></P>

<P><FONT SIZE=3D2>There may of course be local policies of =
Authentication Services which relate these two, but this is of no =
importance to us here, which I think is Juha's point below.</FONT></P>

<P><FONT SIZE=3D2>To avoid such confusion, it he been suggested that we =
do not use Network-Asserted-Identity: as the header name. =
'Asserted-Identity:' is currently top of the poll. If you don't like =
this header name, 'speak now or forever hold your peace'.</FONT></P>

<P><FONT SIZE=3D2>...Mark</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: jh@lohi.eng.song.fi [<A =
HREF=3D"mailto:jh@lohi.eng.song.fi">mailto:jh@lohi.eng.song.fi</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: 11 May 2002 06:49</FONT>
<BR><FONT SIZE=3D2>&gt; To: Robert Sparks</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip@ietf.org; Jon Peterson</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [Sip] Comment on =
sip-identity-00</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; there seems to be lots of confusion about what =
&quot;authenticated </FONT>
<BR><FONT SIZE=3D2>&gt; identity&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; of a sip user is.&nbsp; in our network it is =
simply the Network Access</FONT>
<BR><FONT SIZE=3D2>&gt; Identity (NAI) of the user, e.g., =
foo@bar.com.&nbsp; that same NAI is used</FONT>
<BR><FONT SIZE=3D2>&gt; for all services the user has subscribed to, =
e.g., email, </FONT>
<BR><FONT SIZE=3D2>&gt; remote access,</FONT>
<BR><FONT SIZE=3D2>&gt; and sip, and thus is not sip specific.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; the NAI does necessarily have NOTHING to do =
with the sip uri that the</FONT>
<BR><FONT SIZE=3D2>&gt; user registers and want to be known by.&nbsp; =
for example, the </FONT>
<BR><FONT SIZE=3D2>&gt; user with NAI</FONT>
<BR><FONT SIZE=3D2>&gt; foo@bar.com may want to register a sip uri =
</FONT>
<BR><FONT SIZE=3D2>&gt; sip:+358333983900@bar.com or</FONT>
<BR><FONT SIZE=3D2>&gt; several sip uris of that or other sort.&nbsp; =
the user specifically may NOT</FONT>
<BR><FONT SIZE=3D2>&gt; want to register as sip:foo@bar.com.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; my conclusion of all this is that the =
authentication server </FONT>
<BR><FONT SIZE=3D2>&gt; must verify</FONT>
<BR><FONT SIZE=3D2>&gt; both the NAI of the user and the sip uri of the =
user that the user has</FONT>
<BR><FONT SIZE=3D2>&gt; placed in the from header or, in case of an =
anonymous call, in some</FONT>
<BR><FONT SIZE=3D2>&gt; other header of the message.&nbsp; it seems to =
me that for the </FONT>
<BR><FONT SIZE=3D2>&gt; other parties</FONT>
<BR><FONT SIZE=3D2>&gt; to which the message is forwarded to, it is =
enough that the</FONT>
<BR><FONT SIZE=3D2>&gt; authenticated sip uri is included in the =
message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; regarding the i-d on the subject line, the =
distinction between the NAI</FONT>
<BR><FONT SIZE=3D2>&gt; and sip uris of the user should be clarified =
before we can go on.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- juha</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; _______________________________________________<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1FA74.2543D5BC--

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



From daemon@optimus.ietf.org  Mon May 13 21:38:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13459
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 21:38:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA10443
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:39:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17598;
	Mon, 13 May 2002 14:24:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17567
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 14:24:17 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24039
	for <sip@ietf.org>; Mon, 13 May 2002 14:23:52 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4DINXd10348;
	Mon, 13 May 2002 13:23:33 -0500
Message-ID: <031801c1faab$4b784790$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Dean Willis" <dean.willis@softarmor.com>, <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, "'Allison Mankin'" <mankin@isi.edu>,
        <brian.rosen@cisco.com>, <jo@ipdialog.com>, <rsparks@dynamicsoft.com>
References: <00b101c1f229$22ae8c50$1e036e3f@TXDWILLIS2>
Subject: Closed: Re: [Sip] WGLC for Refer Draft
Date: Mon, 13 May 2002 13:23:34 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Ok, we're moving this to IETF last call now.

Working group comments were addressed and the document reissued as
draft-ietf-sip-refer-02.

--
Dean

----- Original Message -----
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "'Rohan Mahy'" <rohan@cisco.com>; "'Allison Mankin'"
<mankin@isi.edu>; <brian.rosen@cisco.com>; <jo@ipdialog.com>;
<rsparks@dynamicsoft.com>
Sent: Thursday, May 02, 2002 5:31 PM
Subject: [Sip] WGLC for Refer Draft


>
> I'd like to request Working Group Last Call for the REFER method.
>
> The current version is availabe as:
>
>
http://www.softarmor.com/sipwg/drafts/draft-sparks-sip-refer-split-00.tx
> t
>
> Or
>
>
http://search.ietf.org/internet-drafts/draft-sparks-sip-refer-split-00.t
> xt
>
>
> We need to close this by app May 21, so get your comments in. Please
> copy the list AND Rober tSparks, who will consolidate responses.
>
> --
> 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 daemon@optimus.ietf.org  Mon May 13 21:41:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13543
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 21:41:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA10599
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:42:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29802;
	Mon, 13 May 2002 08:42:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29770
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 08:42:16 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06938
	for <sip@ietf.org>; Mon, 13 May 2002 08:42:03 -0400 (EDT)
Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian))
	id 177F9J-0001n7-00; Mon, 13 May 2002 15:41:57 +0300
From: Juha Heinanen <jh@lohi.eng.song.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15583.46229.215256.863288@lohi.eng.song.fi>
Date: Mon, 13 May 2002 15:41:57 +0300
To: "Mark Watson"<mwatson@nortelnetworks.com>
Cc: Robert Sparks
	 <rsparks@dynamicsoft.com>, sip@ietf.org,
        Jon Peterson <jon.peterson@neustar.biz>
Subject: RE: [Sip] Comment on sip-identity-00
In-Reply-To: <A3C2399B2FACD411A54200508BE39C74054F720C@zwcwd00r.europe.nortel.com>
References: <A3C2399B2FACD411A54200508BE39C74054F720C@zwcwd00r.europe.nortel.com>
X-Mailer: VM 6.97 under Emacs 20.7.2
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

mark,

the point of my message was not the same of the header field, but what
you mean by network asserted indetify and how it relates to the any
number of sip uris that the user may have.

-- 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 daemon@optimus.ietf.org  Mon May 13 21:42:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13563
	for <sip-archive@odin.ietf.org>; Mon, 13 May 2002 21:42:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA10614
	for sip-archive@odin.ietf.org; Mon, 13 May 2002 21:42:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11965;
	Mon, 13 May 2002 12:25:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11906
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 12:25:12 -0400 (EDT)
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18566
	for <sip@ietf.org>; Mon, 13 May 2002 12:24:59 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4DGOYI27696;
	Mon, 13 May 2002 11:24:34 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZRPJ4>; Mon, 13 May 2002 11:24:29 -0500
Message-ID: <70565611B164D511957A001083FCDD56018702E0@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Robert Sparks'" <rsparks@dynamicsoft.com>, sip@ietf.org
Date: Mon, 13 May 2002 11:24:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] RE: Comment on sip-identity-00
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


These are good points; throughout the identity draft, I tried to use Digest
only as an example, and indeed in plenty of authentication systems the
identifier of a user would not be suitable syntactically or semantically for
the username portion of a SIP URI. I do think it is not unreasonable,
however, in systems like Digest for a user to have an expectation that the
username they enter into an authentication dialog (for example) will be the
username that appears in their authenticated identity. However, there is as
you suggest no need for this to be mandated normatively by the standard.
Perhaps we could add some language to 4.2 that would explain some of these
issues.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Friday, May 10, 2002 12:58 PM
> To: sip@ietf.org; Jon Peterson
> Subject: Comment on sip-identity-00
> 
> 
> Paragraph 2 of 4.2 binds the username part of
> credentials (such as DIGEST credentials) to an
> identity represented as a SIP URI by algorithmically
> placing that username into the user portion of the URI.
> 
> This instead should be policy at the authentication
> service. That service knows how to bind whatever
> credentials it was given to an identity. Presumably,
> since it is a SIP identity service, it knows how to
> express that identity as a SIP URI.
> 
> Using the algorithm suggested will create problems
> for existing realms where the username "alice" is
> owned by someone other than the person who owns
> "alice@atlanta.com". It also wouldn't work for 
> other credentialing methods where the analog of
> username isn't syntactically valid for the user 
> portion of a SIP URI.
> 
> 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 daemon@optimus.ietf.org  Tue May 14 03:44:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07270
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 03:44:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA13677
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 03:44:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11162;
	Tue, 14 May 2002 03:08:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11097
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 03:07:51 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05540
	for <sip@ietf.org>; Tue, 14 May 2002 03:07:38 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4E77js7023186;
	Tue, 14 May 2002 09:07:45 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4E77i9q005278;
	Tue, 14 May 2002 10:07:44 +0300 (EET DST)
Message-ID: <3CE0B7C0.C4A1F003@lmf.ericsson.se>
Date: Tue, 14 May 2002 10:07:44 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip <sip@ietf.org>
CC: Sanjoy Sen <sanjoy@nortelnetworks.com>,
        "'tao.haukka@nokia.com'" <tao.haukka@nokia.com>,
        Jari.Arkko@lmf.ericsson.se, vesa.torvinen@lmf.ericsson.se
References: <933FADF5E673D411B8A30002A5608A0E03A63273@zrc2c012.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Version 01 of sec-agree just released
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

We have just released a new version of the security agreement draft.
Until it appears in the archives, you can fecth it from:

http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sec-agree-01.txt

We have incorporated all the feedback that we received during the
interim meeting in Las Vegas. The syntax has been fixed and now it
follows the general syntax for SIP extensions.

We have also narrowed down the scope of the draft. Now it only solves
the security negotation between the UA and the first-hop proxy. Thanks
to this limitation in the scope of the solution, we have been able to
remove any URI, host name or IP address in the security header fields
(the old and controversial to and from parameters within these header
fields). 

We have also added a couple of examples that illustrate the use of the
mechanism described in the draft.

As usual, feedback on this document is appreciated.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@ns.ietf.org  Tue May 14 11:08:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22645
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 11:08:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA16357
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 11:08:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14308;
	Tue, 14 May 2002 10:40:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14276
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 10:40:44 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21630
	for <sip@ietf.org>; Tue, 14 May 2002 10:40:29 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4EEeaX94100;
	Tue, 14 May 2002 09:40:37 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: [Sip] Message draft changes
Date: Tue, 14 May 2002 09:40:25 -0500
Message-ID: <HNEOJECGFHIABDLENMMCKEIHCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE214@esebe013.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Tuesday, May 14, 2002 4:54 AM
> To: sip@ietf.org
> Cc: bcampbell@dynamicsoft.com
> Subject: RE: [Sip] Message draft changes
>
>
> Hi Ben,
>
> > I submitted draft-ietf-sip-message-04 last week. This version
> > contains a few
> > AD requested changes, primarily in the area of congestion control.
> > Specifically:
> >
> > 1) Added an applicability statement clarifying the difference
> > between the
> > pager and session models, and that this draft only defines
> > the pager model.
> >
> > 2) Strengthened the congestion control section:
> >
> >    * 1300 byte hard limit for physical payload size for pager
> > model. This
> > applies to the actual payload only, not indirect content. Fragmenting
> > content across multiple requests is prohibited for pager model.
>
> I don't agree with this at all. This sort of hard limit really
> hampers the whole IM application. The session mode and paging
> mode IM are very different in nature. Session IM is clearly
> conversational, whereas paging mode IM much more of a
> "shoot-and-forget" type messaging. Now if the selection between
> the two is not based on user preference and needs but on payload
> size, I don't think this serves the IM users very well.
>
> Also, 1300 bytes seems awfully little, if I want to send
> message/cpim with S/MIME protection.
>

I understand your concern. The problem is, the IESG is very concerned about
the potential for congestion caused by MESSAGE. We initially stated that, if
your payload was over 1300 bytes, you must use a congestion-controlled
transport. The SIP spec itself says that now, I think. The problem is,
outside of a dialog, there is no way to ensure that no hop will traverse
UDP. So to allow larger payloads, we would have to solve that problem first.
We did not want to make MESSAGE dependent on a solution for that problem.

There is work underway to define a mechanism for indirect content. I think
we will have to use that for any sort of large content.


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



From daemon@ns.ietf.org  Tue May 14 14:46:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00154
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 14:46:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA10271
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 14:46:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06835;
	Tue, 14 May 2002 14:12:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05337
	for <sip@ns.ietf.org>; Tue, 14 May 2002 13:45:34 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28112
	for <sip@ietf.org>; Tue, 14 May 2002 13:45:20 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id AD3C57B200B8; Tue, 14 May 2002 13:45:32 -0400
Message-ID: <001301c1fb6f$4f614180$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Robert Sparks" <rsparks@dynamicsoft.com>, <sip@ietf.org>
Date: Tue, 14 May 2002 13:46:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] missing text in draft-ietf-sip-refer-03.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Robert,

Sorry for not reporting this earlier, but I only got a chance to look at the
draft today.

It appears that a significant chunk of text has been removed from the refer
draft that probably needs to be restored:

In section 2, immediately after "REFER is a SIP method as defined by RFC3261
[1]. The REFER method indicates that the recipient (identified by the
Request-URI) should" it used to say:

   contact a third party using the contact information provided in the
   method.  A success response indicates that the recipient was able to
   contact the third party.

   Unless stated otherwise, the protocol for emitting and responding to
   a REFER request are identical to those for a BYE request in [1].  The
   behavior of SIP entities not implementing the REFER (or any other
   unknown) method is explicitly defined in [1].

   A REFER request MAY be placed outside the scope of a dialog created
   with an INVITE.  REFER MAY be Record-Routed, hence MUST contain a
   single Contact header.  REFERs occurring inside an existing dialog
   MUST follow the Route/Record-Route logic of that dialog.  REFERs
   occurring outside an existing dialog effectively create a new dialog
   following the behavior of SUBSCRIBE specified [2].

3.1 The Refer-To Header

   Refer-To is a request-header as defined by [1].  It may only appear
   in a REFER request.  It provides a URL to reference.

The current text makes no sense to me:

   REFER is a SIP method as defined by RFC3261 [1].  The REFER method
   indicates that the recipient (identified by the Request-URI) should
   be interpreted as if it appeared in Table 3 of RFC 3261.


cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.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 daemon@ns.ietf.org  Tue May 14 14:48:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00277
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 14:48:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA10510
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 14:48:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06802;
	Tue, 14 May 2002 14:12:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05337
	for <sip@ns.ietf.org>; Tue, 14 May 2002 13:45:34 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28112
	for <sip@ietf.org>; Tue, 14 May 2002 13:45:20 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id AD3C57B200B8; Tue, 14 May 2002 13:45:32 -0400
Message-ID: <001301c1fb6f$4f614180$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Robert Sparks" <rsparks@dynamicsoft.com>, <sip@ietf.org>
Date: Tue, 14 May 2002 13:46:43 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Sip] missing text in draft-ietf-sip-refer-03.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Robert,

Sorry for not reporting this earlier, but I only got a chance to look at the
draft today.

It appears that a significant chunk of text has been removed from the refer
draft that probably needs to be restored:

In section 2, immediately after "REFER is a SIP method as defined by RFC3261
[1]. The REFER method indicates that the recipient (identified by the
Request-URI) should" it used to say:

   contact a third party using the contact information provided in the
   method.  A success response indicates that the recipient was able to
   contact the third party.

   Unless stated otherwise, the protocol for emitting and responding to
   a REFER request are identical to those for a BYE request in [1].  The
   behavior of SIP entities not implementing the REFER (or any other
   unknown) method is explicitly defined in [1].

   A REFER request MAY be placed outside the scope of a dialog created
   with an INVITE.  REFER MAY be Record-Routed, hence MUST contain a
   single Contact header.  REFERs occurring inside an existing dialog
   MUST follow the Route/Record-Route logic of that dialog.  REFERs
   occurring outside an existing dialog effectively create a new dialog
   following the behavior of SUBSCRIBE specified [2].

3.1 The Refer-To Header

   Refer-To is a request-header as defined by [1].  It may only appear
   in a REFER request.  It provides a URL to reference.

The current text makes no sense to me:

   REFER is a SIP method as defined by RFC3261 [1].  The REFER method
   indicates that the recipient (identified by the Request-URI) should
   be interpreted as if it appeared in Table 3 of RFC 3261.


cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.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 daemon@ns.ietf.org  Tue May 14 15:00:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00864
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 15:00:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA11441
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 15:00:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09691;
	Tue, 14 May 2002 14:34:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA09657
	for <sip@ns.ietf.org>; Tue, 14 May 2002 14:34:31 -0400 (EDT)
Received: from crash.dfw.dynamicsoft.com ([63.110.3.64])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29598
	for <sip@ietf.org>; Tue, 14 May 2002 14:34:17 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4EIbxV21266
	for <sip@ietf.org>; Tue, 14 May 2002 13:37:59 -0500
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip@ietf.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 
Date: 14 May 2002 13:32:29 -0500
Message-Id: <1021401149.1226.10.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: [Sip] REFER updated to -04
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

draft-sparks-sip-refer-split-00 and draft-ietf-sip-refer-03
had a fairly major chunk of text missing. Bob Penfield caught
the mistake. I have corrected it have submitted the correction
as draft-ietf-sip-refer-04.

Until it shows up in the archives, you can get it at
http://www.nostrum.com/~rjsparks/draft-ietf-sip-refer-04.txt


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 daemon@ns.ietf.org  Tue May 14 15:10:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01299
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 15:10:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA12442
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 15:10:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10108;
	Tue, 14 May 2002 14:44:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10077
	for <sip@ns.ietf.org>; Tue, 14 May 2002 14:43:59 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00013;
	Tue, 14 May 2002 14:43:44 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4EIhQd18638;
	Tue, 14 May 2002 13:43:26 -0500
Message-ID: <01cb01c1fb77$429f2310$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: <iesg-secretary@ietf.org>, <internet-drafts@ietf.org>, <sip@ietf.org>
Cc: "Bernhard Honeisen" <bernhard.honeisen@nokia.com>, <mankin@isi.edu>
Date: Tue, 14 May 2002 13:43:37 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Revision of draft-willis-sip-path to version -07
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

We have previously requested IETF last call on draft-willis-sip-path.

Sharp-eyed Vijay found a couple of minor typos that, though previously
thought  fixed, didn't stay fixed. This annoyed me enough that I fixed
them and revved the draft, although there are no technical changes.

The version-07 draft can be retrieved from:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.html
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.xml

Internet-Drafts -- please post this draft and announce to SIP WG list
IESG-Secretary -- please repalce the reference to -06 on the calendar
with a reference to -07.

Thank you all.

--
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 daemon@ns.ietf.org  Tue May 14 15:16:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01529
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 15:16:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA12753
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 15:16:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11292;
	Tue, 14 May 2002 14:59:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11261
	for <sip@ns.ietf.org>; Tue, 14 May 2002 14:59:45 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00806;
	Tue, 14 May 2002 14:59:31 -0400 (EDT)
Message-Id: <200205141859.OAA00806@ietf.org>
To: IETF-Announce: ;
Cc: sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Tue, 14 May 2002 14:59:31 -0400
Subject: [Sip] Last Call: Session Initiation Protocol Extension for Instant
 Messaging to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol
Working Group to consider Session Initiation Protocol Extension for
Instant Messaging <draft-ietf-sip-message-04.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 any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by May 28, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt



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



From daemon@ns.ietf.org  Tue May 14 16:14:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04514
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 16:14:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA20442
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 16:14:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16574;
	Tue, 14 May 2002 15:53:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16546
	for <sip@ns.ietf.org>; Tue, 14 May 2002 15:53:37 -0400 (EDT)
Received: from smtp6.arnet.com.ar (smtp6.arnet.com.ar [200.45.191.24])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03313
	for <sip@ietf.org>; Tue, 14 May 2002 15:53:21 -0400 (EDT)
Received: (qmail 18650 invoked from network); 14 May 2002 19:54:46 -0000
Received: from unknown (HELO arnet.com.ar) (200.45.0.20)
  by smtp6.arnet.com.ar with SMTP; 14 May 2002 19:54:46 -0000
Received: from mail pickup service by arnet.com.ar with Microsoft SMTPSVC;
	 Tue, 14 May 2002 16:42:45 -0300
Received: from mx2.arnet.com.ar ([200.45.0.3]) by mail2.arnet.com.ar  with Microsoft SMTPSVC(5.5.1877.677.67);
	 Tue, 14 May 2002 16:20:13 -0300
Received: from smtp-mx-02.ti.local ([200.45.48.21]) by mx2.arnet.com.ar  with Microsoft SMTPSVC(5.5.1877.357.35);
	 Tue, 14 May 2002 16:20:13 -0300
Received: from loki.ietf.org ([132.151.1.177]) by smtp-mx-02.ti.local with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 14 May 2002 16:16:41 -0300
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA11760
	for ietf-123-outbound.01@ietf.org; Tue, 14 May 2002 15:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA11633
	for <all-ietf@loki.ietf.org>; Tue, 14 May 2002 14:59:44 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00806;
	Tue, 14 May 2002 14:59:31 -0400 (EDT)
Message-Id: <200205141859.OAA00806@ietf.org>
To: IETF-Announce: ;
Cc: sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Tue, 14 May 2002 14:59:31 -0400
X-OriginalArrivalTime: 14 May 2002 19:16:42.0093 (UTC) FILETIME=[E13439D0:01C1FB7B]
Subject: [Sip] Last Call: Session Initiation Protocol Extension for Instant
 Messaging to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol
Working Group to consider Session Initiation Protocol Extension for
Instant Messaging <draft-ietf-sip-message-04.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 any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by May 28, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-message-04.txt


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



From daemon@ns.ietf.org  Tue May 14 17:47:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08577
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 17:47:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA27315
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 17:47:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25755;
	Tue, 14 May 2002 17:28:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16492
	for <sip@ns.ietf.org>; Tue, 14 May 2002 11:09:38 -0400 (EDT)
Received: from tssg.wit.ie (tssg.wit.ie [193.1.185.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22722
	for <sip@ietf.org>; Tue, 14 May 2002 11:09:22 -0400 (EDT)
Received: from boolard ([10.37.1.56])
	by tssg.wit.ie (8.11.6/8.11.6/SuSE Linux 0.5) with SMTP id g4EF9XV15696
	for <sip@ietf.org>; Tue, 14 May 2002 16:09:33 +0100
From: "Shane McCormack" <smccormack@tssg.org>
To: <sip@ietf.org>
Date: Tue, 14 May 2002 16:11:53 +0100
Message-ID: <HKEILFGJCBMBHOCGMAJNOEEHCCAA.smccormack@tssg.wit.ie>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] SCTP and SIP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi all,
	Just wondering if there is any active work in the area of SIP and SCTP. I
would be interested in hearing of any.

Thanks
Shane



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



From daemon@ns.ietf.org  Tue May 14 17:49:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08653
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 17:49:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA27397
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 17:49:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25041;
	Tue, 14 May 2002 17:20:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25006
	for <sip@ns.ietf.org>; Tue, 14 May 2002 17:20:24 -0400 (EDT)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07371
	for <sip@ietf.org>; Tue, 14 May 2002 17:20:10 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4ELHHne015516;
	Tue, 14 May 2002 17:17:18 -0400 (EDT)
Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id K8ZHHAXT; Tue, 14 May 2002 17:19:52 -0400
Message-ID: <3CE17F78.4050006@dynamicsoft.com>
Date: Tue, 14 May 2002 17:19:52 -0400
From: Anders Kristensen <akristensen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org
Subject: Re: [Sip] Revision of draft-willis-sip-path to version -07
References: <01cb01c1fb77$429f2310$133fed0c@C1893415A>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Dean,

You're still missing a couple:

Line 190 (txt version): "reuqest"
Line 253: "vfield"

Other nits...

Line 46: Does not compute: "The problem is that network topology may be 
that..."

Line 139: is "service proxy" an established term? Why not just "proxy".

Line 141: is "transited" really a real word?

Line 147: "The proposed Path extension header field...". When becoming 
RFC it's no longer a proposal.

Line 172:

    2.  The same set of intervening proxies MUST be visited by requests
        between a home service proxy and the UA.  That is, the proxy
        route between the home service proxy and the UA is the exact
        reverse of the proxy route between the UA and its registrar.

As the draft points out later, this is not, strictly speaking, a 
condition for applicability.  One might end up with a subset of teh path 
travelled by the REGISTER and also, a proxy might insert addresses other 
than its own on the Path.

Line 198:

    The primary difference between Path and Record-Route is that Path
    applies to REGISTER and 200 OK responses to REGISTER.  Record-Route
    doesn't, and can't be defined in REGISTER for reasons of backward
    compatibility.

I'd say the more important difference is that Record-Route applies to 
the dialog being set by the request it's used in whereas Path is used to 
establish a route for subsequent requests.

Line 153:

    The UA should include the option tag "path" as a header vfield value
    in all Supported header fields, and should include a Supported header
    field in all requests.

This make it sound like the path token is optional if the UA inserts a 
Supported header. I believe it's the case that a Supported header must 
always include the tokens for all supported extensions.


Line 331:

    However, the Path
    mechanism should technically work in the absence of UA support (at
    some compromise to security)

I'm not sure I see how a Supported: path header contributes to making 
this more secure. That is, unless you also assume S/MIME and what have you.

BTW, it seems a little schizofrenic to me to say that a registrar may 
ignore absence of "Supported: path" but a proxy can't. In fact, since 
the functioning of the Path header doesn't depend on UA cooperation I'm 
not sure wht it's required at all. Is it so that you get a measure of 
assurance that the UA/human sending the REGISTER knows that things have 
inserted themselves on the path of subsequent requests?

Line 347: "home service proxy" - again, I'd prefer just proxy or home proxy.

Sorry for the late comments.

Anders

Dean Willis wrote:
> We have previously requested IETF last call on draft-willis-sip-path.
> 
> Sharp-eyed Vijay found a couple of minor typos that, though previously
> thought  fixed, didn't stay fixed. This annoyed me enough that I fixed
> them and revved the draft, although there are no technical changes.
> 
> The version-07 draft can be retrieved from:
> 
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.txt
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.html
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-07.xml
> 
> Internet-Drafts -- please post this draft and announce to SIP WG list
> IESG-Secretary -- please repalce the reference to -06 on the calendar
> with a reference to -07.
> 
> Thank you all.
> 
> --
> 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



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



From daemon@ns.ietf.org  Tue May 14 18:06:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09204
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:06:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA28302
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:06:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24979;
	Tue, 14 May 2002 06:18:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24919
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 06:18:44 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11801
	for <sip@ietf.org>; Tue, 14 May 2002 06:18:31 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4EAIg0E013264
	for <sip@ietf.org>; Tue, 14 May 2002 12:18:42 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4EAIg9q018640
	for <sip@ietf.org>; Tue, 14 May 2002 13:18:42 +0300 (EET DST)
Message-ID: <3CE0E481.6DC961ED@lmf.ericsson.se>
Date: Tue, 14 May 2002 13:18:41 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Reason version 01
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

I have just released version 01 of the Reason draft. Until it appears in
the archives, you can fetch it from:
http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-reason-01.txt

Only minor modifications has been done since version 00.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@ns.ietf.org  Tue May 14 18:12:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09398
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:12:30 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA28460
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:12:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23135;
	Tue, 14 May 2002 05:54:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23102
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 05:54:06 -0400 (EDT)
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10979
	for <sip@ietf.org>; Tue, 14 May 2002 05:53:53 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4E9tPd26645
	for <sip@ietf.org>; Tue, 14 May 2002 12:55:26 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5adb739b7eac158f21083@esvir01nok.ntc.nokia.com>;
 Tue, 14 May 2002 12:54:03 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Tue, 14 May 2002 12:54:03 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] Message draft changes
Date: Tue, 14 May 2002 12:54:02 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE214@esebe013.NOE.Nokia.com>
Thread-Topic: [Sip] Message draft changes
Thread-Index: AcH6sug2uHCL58EmRGGSXoJ6S9ed2AAei/dw
To: <sip@ietf.org>
Cc: <bcampbell@dynamicsoft.com>
X-OriginalArrivalTime: 14 May 2002 09:54:03.0357 (UTC) FILETIME=[476DE8D0:01C1FB2D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA23103
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi Ben,

> I submitted draft-ietf-sip-message-04 last week. This version 
> contains a few
> AD requested changes, primarily in the area of congestion control.
> Specifically:
> 
> 1) Added an applicability statement clarifying the difference 
> between the
> pager and session models, and that this draft only defines 
> the pager model.
> 
> 2) Strengthened the congestion control section:
> 
>    * 1300 byte hard limit for physical payload size for pager 
> model. This
> applies to the actual payload only, not indirect content. Fragmenting
> content across multiple requests is prohibited for pager model.

I don't agree with this at all. This sort of hard limit really hampers the whole IM application. The session mode and paging mode IM are very different in nature. Session IM is clearly conversational, whereas paging mode IM much more of a "shoot-and-forget" type messaging. Now if the selection between the two is not based on user preference and needs but on payload size, I don't think this serves the IM users very well. 

Also, 1300 bytes seems awfully little, if I want to send message/cpim with S/MIME protection.
 
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 daemon@ns.ietf.org  Tue May 14 18:14:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09468
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:14:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA28499
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:14:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01974;
	Tue, 14 May 2002 08:02:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01902
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 08:02:01 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14400;
	Tue, 14 May 2002 08:01:46 -0400 (EDT)
Message-Id: <200205141201.IAA14400@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 14 May 2002 08:01:46 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-03.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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 Refer Method
	Author(s)	: R. Sparks
	Filename	: draft-ietf-sip-refer-03.txt
	Pages		: 16
	Date		: 13-May-02
	
This document defines the REFER method.  This SIP extension requests
that the recipient REFER to a resource provided in the request.  This
can be used to enable many applications, including Call Transfer.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-refer-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-refer-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:	<20020513150509.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@ns.ietf.org  Tue May 14 18:28:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09797
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:28:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA28927
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:29:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24773;
	Tue, 14 May 2002 06:17:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24717
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 06:17:13 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11718
	for <sip@ietf.org>; Tue, 14 May 2002 06:17:00 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4EAH6s7006920;
	Tue, 14 May 2002 12:17:06 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4EAH59q018502;
	Tue, 14 May 2002 13:17:05 +0300 (EET DST)
Message-ID: <3CE0E420.1A142D27@lmf.ericsson.se>
Date: Tue, 14 May 2002 13:17:04 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ignacio.Almar@nokia.com
CC: sip@ietf.org
Subject: Re: [Sip] Sending SOAP over SIP
References: <05C8D36DA4EF684D8BD4E309B1CD5AF166DFC7@maebe001.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

inline:

Ignacio.Almar@nokia.com wrote:
> 
> hi all,
> 
>         Thanks in advance.
> 
>         To send SOAP over HTTP, the tag 'SOAPAction' is sent in the HTTP headers when sending SOAP requests to identify the intent of the request. This header can be used by the Firewalls and Proxies to filter the SOAP Message. In HTTP this field is defined as mandatory, so the client MUST include this field in the HTTP header when sending a SOAP message. SOAP can be sent over HTTP as a ContentType=text/xml, and over SIP with the same content type.
>         In SIP, to allow the appropiate filtering by proxies there should be defined a SOAPAction field as mandatory in the client request. Do you think if there is something defined regarding this ?

I do not think anybody has defined such a header field.

> 
>         Another option to let the proxies identify that a SOAP message is inside the SIP message would be to define a ContentType=text/soap+xml, but I think that this is not defined currently in IANA.

I do not think this has been registered either.


> 
>         Note that I am trying to avoid the use of a proprietary format, but I am pointing a general format of sending SOAP over SIP. And also, I am referring to individual sessionless calls, including the SOAP code in a single SIP call, not using a SIP call to establish a session (INVITE) and afterwards send a message using HTTP.
> 

could you please elaborate on what you mean by "sessionless calls"?

I do not understand the last paragraph, but it seems that you want to
use SIP only as a transport, without using any of the existing SIP
semantics defined in existing methods. Is that right?

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@ns.ietf.org  Tue May 14 18:29:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09842
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:29:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA28986
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:29:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20011;
	Tue, 14 May 2002 11:37:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19873
	for <sip@ns.ietf.org>; Tue, 14 May 2002 11:37:04 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23752
	for <sip@ietf.org>; Tue, 14 May 2002 11:36:51 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id AF15B1001FE; Tue, 14 May 2002 11:36:53 -0400
Message-ID: <000901c1fb5c$a0dd3860$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
        "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>, <sip@ietf.org>
Cc: "Bernhard Honeisen" <bernhard.honeisen@nokia.com>
References: <004c01c1fad6$da23d010$133fed0c@C1893415A>
Subject: Re: [Sip] Revised draft: draft-willis-sip-path-06
Date: Tue, 14 May 2002 11:32:59 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Here are some comments on the new path draft.

Section 1, 1st paragraph: s/p roxies/proxies/

Section 2: There is an inconsistency between the applicability statement
(point 2) and the statement in section 4.2 that the path-vector can be
discongruent with the route taken by the REGISTER request. I think the
statement in 4.2 is fine, but the applicability statement seems to prohibit
it.

Section 2: Is the MUST in point 2 of the applicability statement an RFC 2119
MUST? Also, does the document need an RFC 2119 terminology section?

Section 3, Last paragraph on page 4: Suggest changing "Support for the Path
header field may be indicated by...." to "Support for the Path header *is*
indicated by..." (or "is usually") since a UA is suppose to include the
Supported header to indicate its wiliness to have a path applied.

Section 4.1, 2nd paragraph: Does this need to be a normative statement "The
UA SHOULD include the option tag..."?

Section 4.1, 2nd paragraph: s/vfield/field/

Section 4.2, last paragraph: s/alterany/alter any/

Section 4.2, last sentence: This implies that proxies may alter Path header
values, but the table 3 addition on page 5 does not allow it. Under what
circumstances would a proxy alter the path values? RFC 3261 allows a proxy
to modify Record-Route in a response (according to table 3 & section 16.7),
but only the value that the proxy inserted. Do we need a similar requirement
here?

Section 4.3, 2nd paragraph: Should this note on the lr parameter be moved to
section 4.2 since it applies to the proxy rather than the registrar?

Section 4.3, 3rd paragraph: Do we need a normative statement here? Say "The
RECOMMENDED policy is for the registrar....".

Section 4.3, 3rd paragraph: I says a 420 is sent in the response. Shouldn't
this be a 421 (Extension Required) because the UA did not include
Supported:path. If it sends 420 with Unsupported: path, the UA won't know
what to do if it does not understand the path extension. Based on section
4.2, we are assuming that if there is a Require: path present, that an
intermediate proxy inserted it. Sending 420 assumes the UA put in
Require:path. If there is no Require:path, then 420 is definitely the wrong
response.

Section 4.5.1: a nit, but the REGISTER responses in the example do not have
a To tag as required by RFC 3261.

Section 5.1, last paragraph, next to last line:
s/that an intermediate has altered/that an intermediate proxy has altered/

Section 5.2, last paragraph: s/In addtion to/In addition to/

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.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 daemon@ns.ietf.org  Tue May 14 18:40:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10280
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:40:54 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA29888
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:41:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05472;
	Tue, 14 May 2002 01:37:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05436
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 01:37:50 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23598
	for <sip@ietf.org>; Tue, 14 May 2002 01:37:38 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4E5b7d14049;
	Tue, 14 May 2002 00:37:07 -0500
Message-ID: <005c01c1fb09$67e4f460$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Cullen Jennings" <fluffy@cisco.com>,
        "Henrikson, Eric H \(Eric\)" <ehenrikson@lucent.com>, <sip@ietf.org>
References: <DLEHICEBMNEIPCACNLPCGECECDAA.fluffy@cisco.com>
Subject: Re: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt
Date: Tue, 14 May 2002 00:37:15 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


The proxy doesn't correlate it. The billing system correlates, using the
"original call ID"

For example:

Here's an example:

You go through an S-CSCF, through an anonymizer AS and out to a partner
company (but we still want you to be anonymized from them so they don't
send you spam later) for gateway services. The partner company sends
charging records back. We want to be able to correlate the charging
records (keyed by OrigID) with the records written by the S-CSCF.
Actually, I just realized that this anonymization trick would be useful
for statistical "blind sampling" of the veracity of a partner's billing
system. You heard it first here folks!

DCS had a very similar header called the DCS billing ID or something
like that.

--
Dean


----- Original Message -----
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>; "Dean Willis"
<dean.willis@softarmor.com>; <sip@ietf.org>
Sent: Monday, May 13, 2002 10:55 PM
Subject: RE: [Sip] Expert Review:
draft-henrikson-sip-original-dialog-id-01.txt


>
> I don't understand why the proxy, P1, that sent the call to the AS (a
> B2BUA), would need to correlate the call that came back from the AS
with the
> original call that P1 sent to the AS. Are there any requirements of
what we
> are trying to solve here?
>
>
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> > Henrikson, Eric H (Eric)
> > Sent: Tuesday, May 07, 2002 9:55 AM
> > To: Dean Willis; sip@ietf.org
> > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com;
'Allison
> > Mankin'; Drage, Keith (Keith)
> > Subject: [Sip] Expert Review:
> > draft-henrikson-sip-original-dialog-id-01.txt
> >
> >
> > Attached is revision 01 of the original-dialog-id draft.
> >
> > Please return comments by May 10, 2002.
> >
> >
> > Thank you.
> > Eric Henrikson
> >
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: Wednesday, May 01, 2002 6:38 AM
> > To: sip@ietf.org
> > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com;
'Allison
> > Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric)
> > Subject: Expert Review:
draft-henrikson-sip-original-dialog-id-00.txt
> >
> >
> >
> > The SIP working group has been asked to provide expert review of
> > draft-henrikson-sip-original-dialog-id. This documents a P-header
used
> > in 3GPP to associate dialogs across a 3GPP application server acting
as
> > a back-to-back user agent.
> >
> > We'd like to complete expert review by May 10, 2002.
> >
> > Please copy your comments to the list and to Keith Drage and Eric
> > Henrikson, who will coordinate responses and edit the draft
> > apporpriately.
> >
> > Thanks,
> >
> > --
> > 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 daemon@ns.ietf.org  Tue May 14 18:42:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10341
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:42:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA29917
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:42:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12920;
	Tue, 14 May 2002 10:24:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12878
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 10:24:00 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20892
	for <sip@ietf.org>; Tue, 14 May 2002 10:23:46 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4EENDs7017024;
	Tue, 14 May 2002 16:23:13 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4EENC9q005028;
	Tue, 14 May 2002 17:23:12 +0300 (EET DST)
Message-ID: <3CE11DD0.7987A687@lmf.ericsson.se>
Date: Tue, 14 May 2002 17:23:12 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Chris Hogg <chogg@nortelnetworks.com>
CC: "'sip@ietf.org'" <sip@ietf.org>,
        "'wtm@research.att.com'" <wtm@research.att.com>,
        "'Gonzalo.Camarillo@ericsson.com'" <Gonzalo.Camarillo@ericsson.com>
References: <D738AA46E980D5119C4B0002A56045FC013C9C46@zwcwc010.europe.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Clarification of Manyfolks-07 and "local" pre-conditions
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

No, it is not a bug in the spec. It is mandated to add two current
status *LINES*. If you are only using local preconditions, the remote
status lines will NOT have the value mandatory.

About the possibility of having multiple preconditions of different
types for the same media line, it is mentioned in the spec. The section
you are referring to is the explanation of the mechanism, and it is kept
simple so that people understand it better. I believe it is better to
explain how preconditions of one type work and then say that you can
have multiple types than trying to explain everything together from the
beginning.

Regards,

Gonzalo

Chris Hogg wrote:
> 
> Hi everyone,
> 
> I've been having a read through of the latest version of Manyfolks
> (Manyfolks-07) and would like to clarify a number of parts of the
> text.
> 
> From section 5.1.1 "SDP encoding"
> 
> "For the segmented status type, the user agent MUST generate two
> current status lines: one with the tag "local" and the other with the
> tag "remote". The user agent MUST add one or two desired status lines
> per segment (i.e., local and remote)."
> 
> And from section 9 "Unknown Precondition type"
> 
> "A UA that receives an unknown precondition-type
>  with a "mandatory" strength-tag in an offer MUST refuse the offer
>  unless the only unknown mandatory preconditions have the "local" tag.
> 
>  In this case, the UA does not need to be involved in order to meet
>  the preconditions. The UA will ask for confirmation of the
>  preconditions and, when the confirmation arrives, it will resume
>  session establishment."
> 
> From my understanding I thought that the text in section 9 regarding
> the ability of the UAS to accept an offer stating a "local"
> pre-condition that it does not understand was added (after agreement
> on the list) for the reason that there may be occasions whereby there
> are pre-conditions which are local to one end and for which the other
> end's UA does not need to understand (and hence asks for
> "confirmation" of the precondition status in the answer SDP).
> However, the text in section 5.1.1 seems to be mis-aligned with this
> since it requires the offerer to include both "local" and "remote"
> pre-conditions if the "segmented" status type is being used.  This
> would mean if a totally local pre-condition was included in the offer
> (without any associated "remote") then the text in section 9 would
> cause the far-end UA to reject the session with a 580 Pre-condition
> unknown response.  This is not the way I thought that "local to one
> end only with no parallel in the peer acess network" style
> pre-conditions were intended to behave.
> 
> I'm assuming that this is just a bug in the spec.
> 
> I've also noticed (normative) text in section 5 which indicates that
> only one type of pre-condition can be used in a given media stream
> (i.e. either "segmented" or "e2e").
> 
> "The offerer then decides whether it is going to use the end-to-end
>    status type or the segmented status type. If the status type of the
> 
>    media line will be end-to-end...."
> 
> Once again, from my understanding, the text in section 9 was
> introduced because it was agreed there could be some pre-conditions
> which may be local to the one end only and for which there was no
> parallel in the peer access network. It was my understanding, however,
> that given these "local" pre-conditions the SIP network may also
> require to use pre-conditions and that these pre-conditions could be
> either of type "segmented" or "e2e".
> 
> Comments?
> 
> Regards,
> 
> Chris
> 
> Chris Hogg
> Nortel Networks (UK)
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@ns.ietf.org  Tue May 14 18:50:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10607
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:50:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00107
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:51:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05708;
	Tue, 14 May 2002 01:42:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05673
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 01:41:49 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23768
	for <sip@ietf.org>; Tue, 14 May 2002 01:41:37 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4E5eSd14070;
	Tue, 14 May 2002 00:40:28 -0500
Message-ID: <006201c1fb09$dff000d0$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Juha Heinanen" <jh@lohi.eng.song.fi>,
        "Mark Watson" <mwatson@nortelnetworks.com>
Cc: "Robert Sparks" <rsparks@dynamicsoft.com>, <sip@ietf.org>,
        "Jon Peterson" <jon.peterson@neustar.biz>
References: <A3C2399B2FACD411A54200508BE39C74054F720C@zwcwd00r.europe.nortel.com> <15583.46229.215256.863288@lohi.eng.song.fi>
Subject: Re: [Sip] Comment on sip-identity-00
Date: Tue, 14 May 2002 00:40:36 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> mark,
>
> the point of my message was not the same of the header field, but what
> you mean by network asserted indetify and how it relates to the any
> number of sip uris that the user may have.
>
> -- juha
>

Ahah!. I think Juha is hinting that he wants to talk about hinting --
that is, how the UA tells the "anonymization service" WHICH of the many
possible Asserted-Identities it should be asserting, and perhaps about
how the anonymization service decides whether the UA authentically
represents a user authorized to claim that specific identity.

--
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 daemon@ns.ietf.org  Tue May 14 18:52:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10688
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:52:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00174
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:52:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23712;
	Tue, 14 May 2002 00:35:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23655
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 00:35:08 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21297
	for <sip@ietf.org>; Tue, 14 May 2002 00:34:54 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 177U1g-000208-00; Tue, 14 May 2002 07:35:04 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15584.37880.831481.941120@harjus.eng.song.fi>
Date: Tue, 14 May 2002 07:35:04 +0300
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "'Robert Sparks'" <rsparks@dynamicsoft.com>, sip@ietf.org
Subject: [Sip] RE: Comment on sip-identity-00
In-Reply-To: <70565611B164D511957A001083FCDD56018702E0@va02.va.neustar.com>
References: <70565611B164D511957A001083FCDD56018702E0@va02.va.neustar.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Peterson, Jon writes:

 > These are good points; throughout the identity draft, I tried to use Digest
 > only as an example, and indeed in plenty of authentication systems the
 > identifier of a user would not be suitable syntactically or semantically for
 > the username portion of a SIP URI. I do think it is not unreasonable,
 > however, in systems like Digest for a user to have an expectation that the
 > username they enter into an authentication dialog (for example) will be the
 > username that appears in their authenticated identity.

i tried to make this same point.  in our case the username used in
digest authentication is the general NAI (Network Access Identifier) of
the user and the sip network asserted identity i-d cannot that the
username used in the digest authentication (or any other authentication
scheme) has nothing to do with the sip uris the user may have.  the i-d
should make this requirement explicitly clear and also clearly explain
that what is asserted is the sip uri the user wants to use for this
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 daemon@ns.ietf.org  Tue May 14 18:52:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10705
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:52:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00190
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:53:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21305;
	Mon, 13 May 2002 23:55:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA21265
	for <sip@optimus.ietf.org>; Mon, 13 May 2002 23:55:19 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19784
	for <sip@ietf.org>; Mon, 13 May 2002 23:55:05 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4E3sf5M020471;
	Mon, 13 May 2002 20:54:41 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACX19063;
	Mon, 13 May 2002 20:54:53 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Henrikson, Eric H \(Eric\)" <ehenrikson@lucent.com>,
        "Dean Willis" <dean.willis@softarmor.com>, <sip@ietf.org>
Subject: RE: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-01.txt
Date: Mon, 13 May 2002 20:55:05 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCGECECDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <47AF9FA8BB0DD611A75C00A0C9AA883C02605EBB@il0015exch004u.ih.lucent.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I don't understand why the proxy, P1, that sent the call to the AS (a
B2BUA), would need to correlate the call that came back from the AS with the
original call that P1 sent to the AS. Are there any requirements of what we
are trying to solve here?


> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> Henrikson, Eric H (Eric)
> Sent: Tuesday, May 07, 2002 9:55 AM
> To: Dean Willis; sip@ietf.org
> Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison
> Mankin'; Drage, Keith (Keith)
> Subject: [Sip] Expert Review:
> draft-henrikson-sip-original-dialog-id-01.txt
>
>
> Attached is revision 01 of the original-dialog-id draft.
>
> Please return comments by May 10, 2002.
>
>
> Thank you.
> Eric Henrikson
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Wednesday, May 01, 2002 6:38 AM
> To: sip@ietf.org
> Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com; 'Allison
> Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric)
> Subject: Expert Review: draft-henrikson-sip-original-dialog-id-00.txt
>
>
>
> The SIP working group has been asked to provide expert review of
> draft-henrikson-sip-original-dialog-id. This documents a P-header used
> in 3GPP to associate dialogs across a 3GPP application server acting as
> a back-to-back user agent.
>
> We'd like to complete expert review by May 10, 2002.
>
> Please copy your comments to the list and to Keith Drage and Eric
> Henrikson, who will coordinate responses and edit the draft
> apporpriately.
>
> Thanks,
>
> --
> 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 daemon@ns.ietf.org  Tue May 14 18:53:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10731
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:53:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00207
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:53:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12613;
	Tue, 14 May 2002 10:19:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12573
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 10:18:52 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20625
	for <sip@ietf.org>; Tue, 14 May 2002 10:18:33 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEHIi20120;
	Tue, 14 May 2002 16:17:18 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEGSp16260;
	Tue, 14 May 2002 15:16:29 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <K6QRC99R>; Tue, 14 May 2002 15:18:06 +0100
Message-ID: <D738AA46E980D5119C4B0002A56045FC013C9C46@zwcwc010.europe.nortel.com>
From: "Chris Hogg"<chogg@nortelnetworks.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Cc: "'wtm@research.att.com'" <wtm@research.att.com>,
        "'Gonzalo.Camarillo@ericsson.com'" <Gonzalo.Camarillo@ericsson.com>
Date: Tue, 14 May 2002 15:18:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FB52.27C17266"
Subject: [Sip] Clarification of Manyfolks-07 and "local" pre-conditions
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1FB52.27C17266
Content-Type: text/plain;
	charset="iso-8859-1"

Hi everyone,

I've been having a read through of the latest version of Manyfolks
(Manyfolks-07) and would like to clarify a number of parts of the text.

>From section 5.1.1 "SDP encoding"

"For the segmented status type, the user agent MUST generate two
current status lines: one with the tag "local" and the other with the
tag "remote". The user agent MUST add one or two desired status lines
per segment (i.e., local and remote)."

And from section 9 "Unknown Precondition type"

"A UA that receives an unknown precondition-type
 with a "mandatory" strength-tag in an offer MUST refuse the offer
 unless the only unknown mandatory preconditions have the "local" tag.
 In this case, the UA does not need to be involved in order to meet
 the preconditions. The UA will ask for confirmation of the
 preconditions and, when the confirmation arrives, it will resume
 session establishment."

>From my understanding I thought that the text in section 9 regarding the
ability of the UAS to accept an offer stating a "local" pre-condition that
it does not understand was added (after agreement on the list) for the
reason that there may be occasions whereby there are pre-conditions which
are local to one end and for which the other end's UA does not need to
understand (and hence asks for "confirmation" of the precondition status in
the answer SDP).  However, the text in section 5.1.1 seems to be mis-aligned
with this since it requires the offerer to include both "local" and "remote"
pre-conditions if the "segmented" status type is being used.  This would
mean if a totally local pre-condition was included in the offer (without any
associated "remote") then the text in section 9 would cause the far-end UA
to reject the session with a 580 Pre-condition unknown response.  This is
not the way I thought that "local to one end only with no parallel in the
peer acess network" style pre-conditions were intended to behave.

I'm assuming that this is just a bug in the spec.

I've also noticed (normative) text in section 5 which indicates that only
one type of pre-condition can be used in a given media stream (i.e. either
"segmented" or "e2e"). 

"The offerer then decides whether it is going to use the end-to-end
   status type or the segmented status type. If the status type of the
   media line will be end-to-end...."

Once again, from my understanding, the text in section 9 was introduced
because it was agreed there could be some pre-conditions which may be local
to the one end only and for which there was no parallel in the peer access
network. It was my understanding, however, that given these "local"
pre-conditions the SIP network may also require to use pre-conditions and
that these pre-conditions could be either of type "segmented" or "e2e".  

Comments?

Regards,

Chris

Chris Hogg
Nortel Networks (UK)
  

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Clarification of Manyfolks-07 and &quot;local&quot; =
pre-conditions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi everyone,</FONT>
</P>

<P><FONT SIZE=3D2>I've been having a read through of the latest version =
of Manyfolks (Manyfolks-07) and would like to clarify a number of parts =
of the text.</FONT></P>

<P><FONT SIZE=3D2>From section 5.1.1 &quot;SDP encoding&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&quot;For the segmented status type, the user agent =
MUST generate two</FONT>
<BR><FONT SIZE=3D2>current status lines: one with the tag =
&quot;local&quot; and the other with the</FONT>
<BR><FONT SIZE=3D2>tag &quot;remote&quot;. The user agent MUST add one =
or two desired status lines</FONT>
<BR><FONT SIZE=3D2>per segment (i.e., local and remote).&quot;</FONT>
</P>

<P><FONT SIZE=3D2>And from section 9 &quot;Unknown Precondition =
type&quot;</FONT>
</P>

<P><FONT SIZE=3D2>&quot;A UA that receives an unknown =
precondition-type</FONT>
<BR><FONT SIZE=3D2>&nbsp;with a &quot;mandatory&quot; strength-tag in =
an offer MUST refuse the offer</FONT>
<BR><FONT SIZE=3D2>&nbsp;unless the only unknown mandatory =
preconditions have the &quot;local&quot; tag.</FONT>
<BR><FONT SIZE=3D2>&nbsp;In this case, the UA does not need to be =
involved in order to meet</FONT>
<BR><FONT SIZE=3D2>&nbsp;the preconditions. The UA will ask for =
confirmation of the</FONT>
<BR><FONT SIZE=3D2>&nbsp;preconditions and, when the confirmation =
arrives, it will resume</FONT>
<BR><FONT SIZE=3D2>&nbsp;session establishment.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>From my understanding I thought that the text in =
section 9 regarding the ability of the UAS to accept an offer stating a =
&quot;local&quot; pre-condition that it does not understand was added =
(after agreement on the list) for the reason that there may be =
occasions whereby there are pre-conditions which are local to one end =
and for which the other end's UA does not need to understand (and hence =
asks for &quot;confirmation&quot; of the precondition status in the =
answer SDP).&nbsp; However, the text in section 5.1.1 seems to be =
mis-aligned with this since it requires the offerer to include both =
&quot;local&quot; and &quot;remote&quot; pre-conditions if the =
&quot;segmented&quot; status type is being used.&nbsp; This would mean =
if a totally local pre-condition was included in the offer (without any =
associated &quot;remote&quot;) then the text in section 9 would cause =
the far-end UA to reject the session with a 580 Pre-condition unknown =
response.&nbsp; This is not the way I thought that &quot;local to one =
end only with no parallel in the peer acess network&quot; style =
pre-conditions were intended to behave.</FONT></P>

<P><FONT SIZE=3D2>I'm assuming that this is just a bug in the =
spec.</FONT>
</P>

<P><FONT SIZE=3D2>I've also noticed (normative) text in section 5 which =
indicates that only one type of pre-condition can be used in a given =
media stream (i.e. either &quot;segmented&quot; or &quot;e2e&quot;). =
</FONT></P>

<P><FONT SIZE=3D2>&quot;The offerer then decides whether it is going to =
use the end-to-end</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; status type or the segmented status =
type. If the status type of the</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; media line will be =
end-to-end....&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Once again, from my understanding, the text in =
section 9 was introduced because it was agreed there could be some =
pre-conditions which may be local to the one end only and for which =
there was no parallel in the peer access network. It was my =
understanding, however, that given these &quot;local&quot; =
pre-conditions the SIP network may also require to use pre-conditions =
and that these pre-conditions could be either of type =
&quot;segmented&quot; or &quot;e2e&quot;.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Comments?</FONT>
</P>

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

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

<P><FONT SIZE=3D2>Chris Hogg</FONT>
<BR><FONT SIZE=3D2>Nortel Networks (UK)</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1FB52.27C17266--

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



From daemon@ns.ietf.org  Tue May 14 18:53:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10770
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:53:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00240
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:54:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15576;
	Tue, 14 May 2002 11:01:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15441
	for <sip@ns.ietf.org>; Tue, 14 May 2002 11:00:38 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22337
	for <sip@ietf.org>; Tue, 14 May 2002 11:00:22 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EExii04237;
	Tue, 14 May 2002 16:59:44 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEwvp24240;
	Tue, 14 May 2002 15:58:57 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <K6QRDB7Z>; Tue, 14 May 2002 16:00:35 +0100
Message-ID: <D738AA46E980D5119C4B0002A56045FC013C9C48@zwcwc010.europe.nortel.com>
From: "Chris Hogg"<chogg@nortelnetworks.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>
Cc: "'sip@ietf.org'" <sip@ietf.org>,
        "'wtm@research.att.com'"
	 <wtm@research.att.com>,
        "'Gonzalo.Camarillo@ericsson.com'"
	 <Gonzalo.Camarillo@ericsson.com>
Date: Tue, 14 May 2002 16:00:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FB58.16B6FF30"
Subject: [Sip] RE: Clarification of Manyfolks-07 and "local" pre-conditions
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1FB58.16B6FF30
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Gonzalo,

Thanks for the quick response.  

Comments in line.

Regards,

Chris.

-----Original Message-----
From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
Sent: 14 May 2002 15:23
To: Hogg, Chris [MDN05:MA01:EXCH]
Cc: 'sip@ietf.org'; 'wtm@research.att.com';
'Gonzalo.Camarillo@ericsson.com'
Subject: Re: Clarification of Manyfolks-07 and "local" pre-conditions


Hello,

>>No, it is not a bug in the spec. It is mandated to add two current
>>status *LINES*. If you are only using local preconditions, the remote
>>status lines will NOT have the value mandatory.

[CH] This was the way I thought the mechanism would work however is it
really necessary to mandate that if you have a pre-condition which is
completely local to one end (and for which there is no parallel requirement
to reserve resources in the peer) to have to include a remote status line
with a strength of "none"?  I'm thinking that if a pre-condition was totally
local to one end then it would be simpler just to send this and not have to
include a "dummy" remote pre-condition tag (with strength sent to "none"). 

>>About the possibility of having multiple preconditions of different
>>types for the same media line, it is mentioned in the spec. The section
>>you are referring to is the explanation of the mechanism, and it is kept
>>simple so that people understand it better. I believe it is better to
>>explain how preconditions of one type work and then say that you can
>>have multiple types than trying to explain everything together from the
>>beginning.

[CH] I understand your concerns for simplicity and that the text I'm
referring to is normative however, I couldn't find any text anywhere
(particularly within the non-normative sections of 5.1.1) saying that, when
constructing the offer, (for a given media line) you could include more than
1 pre-condition type and that "segmented" and "e2e" pre-conditions could
potentially co-exist within the same media line. I think it would be clearer
if it was stated somewhere that this was possible.  If I've missed
something, I'd be happy for you to point out the text to me.

Thanks,
Regards,
Chris.


Regards,

Gonzalo

Chris Hogg wrote:
> 
> Hi everyone,
> 
> I've been having a read through of the latest version of Manyfolks
> (Manyfolks-07) and would like to clarify a number of parts of the
> text.
> 
> From section 5.1.1 "SDP encoding"
> 
> "For the segmented status type, the user agent MUST generate two
> current status lines: one with the tag "local" and the other with the
> tag "remote". The user agent MUST add one or two desired status lines
> per segment (i.e., local and remote)."
> 
> And from section 9 "Unknown Precondition type"
> 
> "A UA that receives an unknown precondition-type
>  with a "mandatory" strength-tag in an offer MUST refuse the offer
>  unless the only unknown mandatory preconditions have the "local" tag.
> 
>  In this case, the UA does not need to be involved in order to meet
>  the preconditions. The UA will ask for confirmation of the
>  preconditions and, when the confirmation arrives, it will resume
>  session establishment."
> 
> From my understanding I thought that the text in section 9 regarding
> the ability of the UAS to accept an offer stating a "local"
> pre-condition that it does not understand was added (after agreement
> on the list) for the reason that there may be occasions whereby there
> are pre-conditions which are local to one end and for which the other
> end's UA does not need to understand (and hence asks for
> "confirmation" of the precondition status in the answer SDP).
> However, the text in section 5.1.1 seems to be mis-aligned with this
> since it requires the offerer to include both "local" and "remote"
> pre-conditions if the "segmented" status type is being used.  This
> would mean if a totally local pre-condition was included in the offer
> (without any associated "remote") then the text in section 9 would
> cause the far-end UA to reject the session with a 580 Pre-condition
> unknown response.  This is not the way I thought that "local to one
> end only with no parallel in the peer acess network" style
> pre-conditions were intended to behave.
> 
> I'm assuming that this is just a bug in the spec.
> 
> I've also noticed (normative) text in section 5 which indicates that
> only one type of pre-condition can be used in a given media stream
> (i.e. either "segmented" or "e2e").
> 
> "The offerer then decides whether it is going to use the end-to-end
>    status type or the segmented status type. If the status type of the
> 
>    media line will be end-to-end...."
> 
> Once again, from my understanding, the text in section 9 was
> introduced because it was agreed there could be some pre-conditions
> which may be local to the one end only and for which there was no
> parallel in the peer access network. It was my understanding, however,
> that given these "local" pre-conditions the SIP network may also
> require to use pre-conditions and that these pre-conditions could be
> either of type "segmented" or "e2e".
> 
> Comments?
> 
> Regards,
> 
> Chris
> 
> Chris Hogg
> Nortel Networks (UK)
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: Clarification of Manyfolks-07 and &quot;local&quot; =
pre-conditions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Gonzalo,</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for the quick response.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Comments in line.</FONT>
</P>

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

<P><FONT SIZE=3D2>Chris.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Gonzalo Camarillo [<A =
HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonzalo.Camaril=
lo@lmf.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: 14 May 2002 15:23</FONT>
<BR><FONT SIZE=3D2>To: Hogg, Chris [MDN05:MA01:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'sip@ietf.org'; 'wtm@research.att.com';</FONT>
<BR><FONT SIZE=3D2>'Gonzalo.Camarillo@ericsson.com'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Clarification of Manyfolks-07 and =
&quot;local&quot; pre-conditions</FONT>
</P>
<BR>

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

<P><FONT SIZE=3D2>&gt;&gt;No, it is not a bug in the spec. It is =
mandated to add two current</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;status *LINES*. If you are only using local =
preconditions, the remote</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;status lines will NOT have the value =
mandatory.</FONT>
</P>

<P><FONT SIZE=3D2>[CH] This was the way I thought the mechanism would =
work however is it really necessary to mandate that if you have a =
pre-condition which is completely local to one end (and for which there =
is no parallel requirement to reserve resources in the peer) to have to =
include a remote status line with a strength of &quot;none&quot;?&nbsp; =
I'm thinking that if a pre-condition was totally local to one end then =
it would be simpler just to send this and not have to include a =
&quot;dummy&quot; remote pre-condition tag (with strength sent to =
&quot;none&quot;). </FONT></P>

<P><FONT SIZE=3D2>&gt;&gt;About the possibility of having multiple =
preconditions of different</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;types for the same media line, it is =
mentioned in the spec. The section</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;you are referring to is the explanation of =
the mechanism, and it is kept</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;simple so that people understand it better. =
I believe it is better to</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;explain how preconditions of one type work =
and then say that you can</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;have multiple types than trying to explain =
everything together from the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt;beginning.</FONT>
</P>

<P><FONT SIZE=3D2>[CH] I understand your concerns for simplicity and =
that the text I'm referring to is normative however, I couldn't find =
any text anywhere (particularly within the non-normative sections of =
5.1.1) saying that, when constructing the offer, (for a given media =
line) you could include more than 1 pre-condition type and that =
&quot;segmented&quot; and &quot;e2e&quot; pre-conditions could =
potentially co-exist within the same media line. I think it would be =
clearer if it was stated somewhere that this was possible.&nbsp; If =
I've missed something, I'd be happy for you to point out the text to =
me.</FONT></P>

<P><FONT SIZE=3D2>Thanks,</FONT>
<BR><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Chris.</FONT>
</P>
<BR>

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

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

<P><FONT SIZE=3D2>Chris Hogg wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi everyone,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I've been having a read through of the latest =
version of Manyfolks</FONT>
<BR><FONT SIZE=3D2>&gt; (Manyfolks-07) and would like to clarify a =
number of parts of the</FONT>
<BR><FONT SIZE=3D2>&gt; text.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; From section 5.1.1 &quot;SDP =
encoding&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;For the segmented status type, the user =
agent MUST generate two</FONT>
<BR><FONT SIZE=3D2>&gt; current status lines: one with the tag =
&quot;local&quot; and the other with the</FONT>
<BR><FONT SIZE=3D2>&gt; tag &quot;remote&quot;. The user agent MUST add =
one or two desired status lines</FONT>
<BR><FONT SIZE=3D2>&gt; per segment (i.e., local and =
remote).&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; And from section 9 &quot;Unknown Precondition =
type&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;A UA that receives an unknown =
precondition-type</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; with a &quot;mandatory&quot; strength-tag =
in an offer MUST refuse the offer</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; unless the only unknown mandatory =
preconditions have the &quot;local&quot; tag.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; In this case, the UA does not need to be =
involved in order to meet</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; the preconditions. The UA will ask for =
confirmation of the</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; preconditions and, when the confirmation =
arrives, it will resume</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; session establishment.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; From my understanding I thought that the text =
in section 9 regarding</FONT>
<BR><FONT SIZE=3D2>&gt; the ability of the UAS to accept an offer =
stating a &quot;local&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; pre-condition that it does not understand was =
added (after agreement</FONT>
<BR><FONT SIZE=3D2>&gt; on the list) for the reason that there may be =
occasions whereby there</FONT>
<BR><FONT SIZE=3D2>&gt; are pre-conditions which are local to one end =
and for which the other</FONT>
<BR><FONT SIZE=3D2>&gt; end's UA does not need to understand (and hence =
asks for</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;confirmation&quot; of the precondition =
status in the answer SDP).</FONT>
<BR><FONT SIZE=3D2>&gt; However, the text in section 5.1.1 seems to be =
mis-aligned with this</FONT>
<BR><FONT SIZE=3D2>&gt; since it requires the offerer to include both =
&quot;local&quot; and &quot;remote&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; pre-conditions if the &quot;segmented&quot; =
status type is being used.&nbsp; This</FONT>
<BR><FONT SIZE=3D2>&gt; would mean if a totally local pre-condition was =
included in the offer</FONT>
<BR><FONT SIZE=3D2>&gt; (without any associated &quot;remote&quot;) =
then the text in section 9 would</FONT>
<BR><FONT SIZE=3D2>&gt; cause the far-end UA to reject the session with =
a 580 Pre-condition</FONT>
<BR><FONT SIZE=3D2>&gt; unknown response.&nbsp; This is not the way I =
thought that &quot;local to one</FONT>
<BR><FONT SIZE=3D2>&gt; end only with no parallel in the peer acess =
network&quot; style</FONT>
<BR><FONT SIZE=3D2>&gt; pre-conditions were intended to behave.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'm assuming that this is just a bug in the =
spec.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I've also noticed (normative) text in section 5 =
which indicates that</FONT>
<BR><FONT SIZE=3D2>&gt; only one type of pre-condition can be used in a =
given media stream</FONT>
<BR><FONT SIZE=3D2>&gt; (i.e. either &quot;segmented&quot; or =
&quot;e2e&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;The offerer then decides whether it is =
going to use the end-to-end</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; status type or the segmented =
status type. If the status type of the</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; media line will be =
end-to-end....&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Once again, from my understanding, the text in =
section 9 was</FONT>
<BR><FONT SIZE=3D2>&gt; introduced because it was agreed there could be =
some pre-conditions</FONT>
<BR><FONT SIZE=3D2>&gt; which may be local to the one end only and for =
which there was no</FONT>
<BR><FONT SIZE=3D2>&gt; parallel in the peer access network. It was my =
understanding, however,</FONT>
<BR><FONT SIZE=3D2>&gt; that given these &quot;local&quot; =
pre-conditions the SIP network may also</FONT>
<BR><FONT SIZE=3D2>&gt; require to use pre-conditions and that these =
pre-conditions could be</FONT>
<BR><FONT SIZE=3D2>&gt; either of type &quot;segmented&quot; or =
&quot;e2e&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Comments?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Chris</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Chris Hogg</FONT>
<BR><FONT SIZE=3D2>&gt; Nortel Networks (UK)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Gonzalo =
Camarillo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :&nbsp; =
+358&nbsp; 9 299 33 71</FONT>
<BR><FONT SIZE=3D2>Oy L M Ericsson =
Ab&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile:&nbsp; +358 40 702 =
35 35</FONT>
<BR><FONT SIZE=3D2>Telecom =
R&amp;D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Fax&nbsp;&nbsp; :&nbsp; +358&nbsp; 9 299 30 =
52</FONT>
<BR><FONT SIZE=3D2>FIN-02420 =
Jorvas&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Email =
:&nbsp; Gonzalo.Camarillo@ericsson.com</FONT>
<BR><FONT =
SIZE=3D2>Finland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.hut.fi/~gonzalo" =
TARGET=3D"_blank">http://www.hut.fi/~gonzalo</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1FB58.16B6FF30--

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



From daemon@ns.ietf.org  Tue May 14 19:27:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10276
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 18:40:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA29875
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 18:41:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01944;
	Tue, 14 May 2002 08:02:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA01890
	for <sip@optimus.ietf.org>; Tue, 14 May 2002 08:01:55 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14384;
	Tue, 14 May 2002 08:01:41 -0400 (EDT)
Message-Id: <200205141201.IAA14384@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 14 May 2002 08:01:41 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-agree-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: Security Mechanism Agreement for SIP Sessions
	Author(s)	: J. Arkko et al.
	Filename	: draft-ietf-sip-sec-agree-01.txt
	Pages		: 16
	Date		: 13-May-02
	
SIP has a number of security mechanisms. Some of them have been built
in to the SIP protocol, such as HTTP authentication or secure
attachments. These mechanisms have even alternative algorithms and
parameters. SIP does not currently provide any mechanism for
selecting which security mechanisms to use over a connection. In
particular, even if some mechanisms such as OPTIONS were used to make
this selection, the selection would be vulnerable against the
Bidding-Down attack. This document defines three header fields for
negotiating the security mechanisms within SIP between a user agent
client and its next hop SIP entity. A SIP entity applying this
mechanism must always require some minimum security (i.e. integrity
protection) from all communicating parties in order to secure the
negotiation, but the negotiation can agree on which specific minimum
security is used.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-sec-agree-01.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-sec-agree-01.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:	<20020513142147.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-sec-agree-01.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@ns.ietf.org  Tue May 14 21:25:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15095
	for <sip-archive@odin.ietf.org>; Tue, 14 May 2002 21:25:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA09952
	for sip-archive@odin.ietf.org; Tue, 14 May 2002 21:25:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07805;
	Tue, 14 May 2002 21:04:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA07767
	for <sip@ns.ietf.org>; Tue, 14 May 2002 21:04:08 -0400 (EDT)
Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14483
	for <sip@ietf.org>; Tue, 14 May 2002 21:03:53 -0400 (EDT)
Received: from victorpc ([206.184.140.167])
	by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g4F146123345;
	Tue, 14 May 2002 21:04:06 -0400
From: "Victor Paulsamy" <victor@zapex.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, "Victor Paulsamy" <victor@zapex.com>
Date: Tue, 14 May 2002 18:02:42 -0700
Message-ID: <NEBBIPNANPGLCDPGFJGPMEIMCEAA.victor@zapex.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-mahy-sipping-join-and-fork-00
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

In e.g., 6.1 Join accepted for local mixing: B&C are in a session. A sends
in an INVITE to B requesting it to add to the existing session (using Join).
How did A learn about the on going session?

Appreciate any response.

Regards,

--victor

Victor Paulsamy               E-mail: victor@zapex.com
Senior Software Engineer      Phone : 650.930.1339 (Direct)
Zapex Technologies, Inc.      Phone : 650.930.1300 (Main)
Mountain View, CA 94043       Fax   : 650.930.1399


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



From daemon@ns.ietf.org  Wed May 15 10:23:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06691
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 10:23:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA24400
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 10:23:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21331;
	Wed, 15 May 2002 09:51:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21293
	for <sip@ns.ietf.org>; Wed, 15 May 2002 09:51:26 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04583
	for <sip@ietf.org>; Wed, 15 May 2002 09:50:59 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4FDoZ626630;
	Wed, 15 May 2002 09:50:36 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id IAA08264; Wed, 15 May 2002 08:50:32 -0500 (CDT)
Message-ID: <3CE267A9.7030608@lucent.com>
Date: Wed, 15 May 2002 08:50:33 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
CC: sip <sip@ietf.org>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: Re: [Sip] Reason version 01
References: <3CE0E481.6DC961ED@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Gonzalo Camarillo wrote:
> Folks,
> 
> I have just released version 01 of the Reason draft. Until it appears in
> the archives, you can fetch it from:
> http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-reason-01.txt
> 
> Only minor modifications has been done since version 00.

Gonzalo:

155 provisional response has been excised from the UPDATE I-D; the
Reason I-D has a now invalid reference which lists the UPDATE I-D for
155 responses.  Additionally, HERFP has also been excised from the
UPDATE I-D, leaving it mainly as a media negotiation method before
the dialog is established.

I believe I saw email from Jonathan on the WG list where he declared
his intention to publish an extension to UPDATE, which lists the 155
response I-D as well as HERFP.  I am wondering if we should define
the 155 provisional response code and HERFP in the Reason I-D, since it
depends on both as use cases.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216


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



From daemon@ns.ietf.org  Wed May 15 10:38:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07553
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 10:38:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA26856
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 10:39:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23524;
	Wed, 15 May 2002 10:15:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23497
	for <sip@ns.ietf.org>; Wed, 15 May 2002 10:15:03 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06028
	for <sip@ietf.org>; Wed, 15 May 2002 10:14:48 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4FEESs0010124;
	Wed, 15 May 2002 07:14:28 -0700 (PDT)
Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AAD89924;
	Wed, 15 May 2002 07:14:27 -0700 (PDT)
Date: Wed, 15 May 2002 07:11:01 -0700 (Pacific Daylight Time)
From: Rohan Mahy <rohan@cisco.com>
To: sip@ietf.org
cc: rohan@cisco.com
Message-ID: <Pine.WNT.4.44.0205150637370.-481001@chorizo.rapidconvergence.com>
X-X-Sender: rmahy@imop.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Sip] WGLC summary for Replaces
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

Other than minor editorial changes, here is a summary of the requests I
have received/changes I have made to replaces.

1) Removed the wildcard to-tag matching and associated proxy behavior.

2) Added authorization behavior to the current UAS behavior section.
Currently the only authorization specified is

3) Added a UAC considerations section

4) Removed the allowance for multiple matched dialogs with no tags.

5) Updated the references

6) Cleaned up the Overview section to be less preachy

All in all the new version is much simpler, more secure, and more robust
than before.  I'll resubmit this morning.

Please contact me if any of these issues are showstoppers.

thanks,
-rohan



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



From daemon@ns.ietf.org  Wed May 15 13:27:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14599
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 13:27:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA14730
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 13:27:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12337;
	Wed, 15 May 2002 12:59:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12311
	for <sip@ns.ietf.org>; Wed, 15 May 2002 12:59:19 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13302
	for <sip@ietf.org>; Wed, 15 May 2002 12:59:05 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4FGwdd26812;
	Wed, 15 May 2002 11:58:40 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Anders Kristensen'" <akristensen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] Revision of draft-willis-sip-path to version -07
Date: Wed, 15 May 2002 11:58:12 -0500
Message-ID: <000901c1fc31$b2c05230$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <3CE17F78.4050006@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Many good comments elided. They will be incorporated in next rev.
Thanks, Anders.

>     The UA should include the option tag "path" as a header 
> vfield value
>     in all Supported header fields, and should include a 
> Supported header
>     field in all requests.
> 
> This make it sound like the path token is optional if the UA 
> inserts a 
> Supported header. I believe it's the case that a Supported 
> header must 
> always include the tokens for all supported extensions.

Yes, this is definitely a slightly different usage of Supported. It's
the closest thing we could come up with to a hinting mechanism, and
probably deserves discussion in its own right. It made Robert Sparks
hair stand on end until he thought about it for a while. But it's
actually pretty cool.

Think about it -- someday we're going to have 1,000 extensions, so every
Supported header is going to be like 20kB long. So the suggested
semantic is that the UA include only those options it is willing to use
for this transaction or any dialog resulting from it, rather than every
possibe supported extension.
 
> 
> Line 331:
> 
>     However, the Path
>     mechanism should technically work in the absence of UA support (at
>     some compromise to security)
> 
> I'm not sure I see how a Supported: path header contributes to making 
> this more secure. That is, unless you also assume S/MIME and 
> what have you.

The Security aspect is that a UA that is aware of Path can look at the
Path header field in the REGISTER response and see what proxies have
attached themselves. This may allow users to detect unwanted proxies
that have "latched on" to registrations. If the UA doesn't support Path,
it is unlikely to able to do this inspection. So it isn't the Supported
header that makes the difference, it's the actual functional support
that matters.

> 
> BTW, it seems a little schizofrenic to me to say that a registrar may 
> ignore absence of "Supported: path" but a proxy can't. In fact, since 
> the functioning of the Path header doesn't depend on UA 
> cooperation I'm 
> not sure wht it's required at all. Is it so that you get a measure of 
> assurance that the UA/human sending the REGISTER knows that 
> things have 
> inserted themselves on the path of subsequent requests?

Yes.

 
> Line 347: "home service proxy" - again, I'd prefer just proxy 
> or home proxy.
> 
> Sorry for the late comments.

The critical piece is that the proxy in question is the proxy
responsible for the address-of-record. It can be expected to do a
retargeting of requests to that AOR by changing the Requist-URI. This
distinguishes it from a proxy that simply forwards using forwarding
rules.  We probably need a distinctive term for such a beast. Please
make suggestions.


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



From daemon@ns.ietf.org  Wed May 15 13:28:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14661
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 13:28:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA14749
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 13:28:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12401;
	Wed, 15 May 2002 12:59:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27361
	for <sip@ns.ietf.org>; Wed, 15 May 2002 10:41:40 -0400 (EDT)
Received: from thorium.btinternet.com (thorium.btinternet.com [194.73.73.67])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07869
	for <sip@ietf.org>; Wed, 15 May 2002 10:41:24 -0400 (EDT)
From: dunc.mills@btinternet.com
Received: from cerium ([194.75.226.98])
	by thorium.btinternet.com with esmtp (Exim 3.22 #8)
	id 177zyD-0006tO-00; Wed, 15 May 2002 15:41:37 +0100
Received: from 193.68.60.25 by cerium ([194.75.226.98]); Wed, 15 May 02 15:41:37 BST
Message-ID: <3409234.1021473697235.JavaMail.root@127.0.0.1>
Date: Wed, 15 May 2002 15:41:37 +0100 (BST)
To: sip@ietf.org, bpenfield@acmepacket.com, duncan.mills@vf.vodafone.co.uk
Subject: Re: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-MAILER: talk21.com WAS v2
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA27374
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Bob,

Many thanks for your comments.  It is re-assuring to know that some IETF experts have reviewed my draft.

Please consider my comments below.  I look forward to your further input, if necessary.

Regards,

Duncan



Hi,

1) The examples given in section 4 (a laptop in an airport or hotel) do not
sound like access networks that will provide the "transitive trust" required
to protect privacy as described in section 6. Are these really valid
examples for usage of this header? Or are you assuming that this would only
work for local ISPs and airports that had a business relationship with the
home network? How does the UA know if these types of access networks can be
trusted?

The model I was thinking of is that the user trusts the access network, because his home network provider trusts the access network.  This is stated in my draft.


2) Does this draft need an explicit Applicability Statement?

I think the draft could be applicable to various systems, but obviously I am writing it primarily with a 3GPP requirement in mind.  Do you think I need to add an explicit Applicability Statement?  My IETF procedural knowledge is (I'm afraid) limited.

3) Section 6 says:

    The serving proxy MUST delete this header before
    forwarding the message outside of the its domain.

but section 7 says:

    A serving proxy, typically located in the home network, and therefore
    trusted, SHOULD delete the header when the SIP signaling is forwarded
    beyond the home network domain

and section 8 says:

    This header SHOULD always be deleted by the serving network prior to
    forwarding it outside of the home network domain, as described in
    section 7.

Is it MUST or SHOULD? Also, I think it is sufficient to have the MUST or
SHOULD once (in the Proxy behavior section) or maybe twice, and then say
"...serving proxies will delete..." in other places you need to talk about
it. I realize it is very important.

You are correct, there is inconsistency.  I'll correct this.

4) The document has weird characters where single quotes (i.e. ') should be.

My version doesn't.  I'll check this out.


5) You say "... where the access-type is æ3GPP-GERANÆ, the access-info
SHALL be "3GPP-CGI".", but go on to says the mapping of access-type to
access-info is defined elsewhere. Can you provide a reference? Also, I don't
think you should use the requirements language (SHALL) for an example like
this. If there are mapping requirement, they should all be included or you
should refer to a document that defines them.

Okay, I was told I couldn't refer to a 3GPP document in an RFC.  I don't think it matters.  The fields specified in the draft are containers that can carry anything anyone defines or doesn't define.  It's just that in our 3GPP specifications, we say "we're going to use the access-network-info header, and we're going to put parameter x in the 'Access-Info' field.  The receiver knows parameter x will be in that field.  I don't want to have this defined in two documents.  Maybe I should just remove the statement saying that it is defined elsewhere?


6) The period is missing between 'request' and 'The' in section 7.1 "... SIP
message request The UAC SHOULD ..."

Thanks.

7) Section 7.1, 2nd paragraph. Should "the nature or the information" be
"the nature *of* the information"?

Ooops.  Thanks.

8) Section 7.2 is labeled "UAS behavior", but talks only about proxy
behavior. I don't think there is any UAS behavior for this header.


Does 'Proxy behaviour' cover the case of a B2BUA?


9) In section 7.2 you say the proxy "MAY use the contents to, e.g., provide
...". I suggest you remove the "e.g." and say something like "... MAY use
the contents to provide a different service or apply performance enhancement
measures depending on the network through which the UA is
accessing the server. For example, ....".


Sounds reasonable, I'll make this change.





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



From daemon@ns.ietf.org  Wed May 15 14:35:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17083
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 14:35:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA20090
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 14:35:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18184;
	Wed, 15 May 2002 14:09:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18155
	for <sip@ns.ietf.org>; Wed, 15 May 2002 14:09:18 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16299
	for <sip@ietf.org>; Wed, 15 May 2002 14:09:03 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4FI8cuF011137
	for <sip@ietf.org>; Wed, 15 May 2002 11:08:38 -0700 (PDT)
Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AAD92568;
	Wed, 15 May 2002 11:08:44 -0700 (PDT)
Date: Wed, 15 May 2002 11:05:18 -0700 (Pacific Daylight Time)
From: Rohan Mahy <rohan@cisco.com>
To: sip@ietf.org
Message-ID: <Pine.WNT.4.44.0205151103470.-481001@chorizo.rapidconvergence.com>
X-X-Sender: rmahy@imop.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Sip] revised version of Replaces available
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

I just submitted a new version of Replaces.  Until it appears in the
archive it is available in the drafts directory on softarmor

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-02.txt

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-02.html

thanks,
-rohan


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



From daemon@ns.ietf.org  Wed May 15 15:20:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18780
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 15:20:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA23264
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 15:20:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21843;
	Wed, 15 May 2002 15:02:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21816
	for <sip@ns.ietf.org>; Wed, 15 May 2002 15:02:41 -0400 (EDT)
Received: from smtp2.arnet.com.ar (smtp2.arnet.com.ar [200.45.191.5])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18024
	for <sip@ietf.org>; Wed, 15 May 2002 15:02:26 -0400 (EDT)
Received: (qmail 678 invoked from network); 15 May 2002 19:01:24 -0000
Received: from unknown (HELO arnet.com.ar) (200.45.0.20)
  by smtp2.arnet.com.ar with SMTP; 15 May 2002 19:01:24 -0000
Received: from mail pickup service by arnet.com.ar with Microsoft SMTPSVC;
	 Wed, 15 May 2002 15:58:52 -0300
Received: from smtp-mx-01.ti.local ([200.45.48.20]) by mx2.arnet.com.ar  with Microsoft SMTPSVC(5.5.1877.357.35);
	 Wed, 15 May 2002 10:09:24 -0300
Received: from loki.ietf.org ([132.151.1.177]) by smtp-mx-01.ti.local with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 15 May 2002 10:05:51 -0300
Received: (from adm@localhost)
	by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA01050
	for ietf-123-outbound.01@ietf.org; Wed, 15 May 2002 09:05:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA00061
	for <all-ietf@loki.ietf.org>; Wed, 15 May 2002 07:12:38 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25814;
	Wed, 15 May 2002 07:12:21 -0400 (EDT)
Message-Id: <200205151112.HAA25814@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 15 May 2002 07:12:21 -0400
X-OriginalArrivalTime: 15 May 2002 13:05:51.0390 (UTC) FILETIME=[3D2A23E0:01C1FC11]
Subject: [Sip] I-D ACTION:draft-ietf-sip-refer-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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 Refer Method
	Author(s)	: R. Sparks
	Filename	: draft-ietf-sip-refer-04.txt
	Pages		: 16
	Date		: 14-May-02
	
This document defines the REFER method.  This SIP extension requests
that the recipient REFER to a resource provided in the request.  This
can be used to enable many applications, including Call Transfer.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-refer-04.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-refer-04.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:	<20020514144207.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-refer-04.txt

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

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

--OtherAccess--

--NextPart--


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



From daemon@ns.ietf.org  Wed May 15 15:48:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20216
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 15:48:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA26267
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 15:48:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23653;
	Wed, 15 May 2002 15:26:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23618
	for <sip@ns.ietf.org>; Wed, 15 May 2002 15:26:56 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18938
	for <sip@ietf.org>; Wed, 15 May 2002 15:26:41 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4FJQr0E023421
	for <sip@ietf.org>; Wed, 15 May 2002 21:26:53 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.106.10])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4FJQq9q000136
	for <sip@ietf.org>; Wed, 15 May 2002 22:26:52 +0300 (EET DST)
Message-ID: <3CE2B67C.11209B4@lmf.ericsson.se>
Date: Wed, 15 May 2002 22:26:52 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Possible ABNF bug
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Hi,

Bis-09 says that the "@" character is not allowed in the SIP-URI (or
SIPS-URI) if the userinfo part of the URI is empty (eg "@sip.world.com"
is not allowed).

However, the ABNF says:


SIP-URI          =  "sip:" [ userinfo "@" ] hostport  uri-parameters [
headers ]

userinfo         =  [ user / telephone-subscriber [ ":" password ]]

Now, the first line (defines SIP-URI) does indicate that userinfo,
together with @, is optional in the URI.

The second line (defines userinfo), however, indicates that user,
telephone-subscriber and password ALSO are optional for userinfo, which
to my understanding means that an empty value IS a valid value for
userinfo.

I think the correct syntax should be:

userinfo         =  ( user / telephone-subscriber [ ":" password ])

Also, does the syntax above password to be used together with user, or
only together with telephone-subscriber? IF so, then I guess the correct
syntax shall be:

userinfo         =  ( user / telephone-subscriber) [ ":" password ]


Regards,

Christer Holmberg
Ericsson Finland





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



From daemon@ns.ietf.org  Wed May 15 18:35:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24335
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 18:35:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA07773
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 18:35:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06684;
	Wed, 15 May 2002 18:20:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06655
	for <sip@ns.ietf.org>; Wed, 15 May 2002 18:20:30 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23952
	for <sip@ietf.org>; Wed, 15 May 2002 18:20:14 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4FMJdd28981;
	Wed, 15 May 2002 17:19:39 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>
Date: Wed, 15 May 2002 17:19:11 -0500
Message-ID: <013001c1fc5e$89fcdc60$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Termination of WGLC, request of IETF LC for draft-ietf-sip-replaces
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I just asked the IESG to schedule an IETF Last Call for the replaces
draft.

Version -02 was submitted to the archive today and supposedly reflects
all changes requested during WGLC. You can also retrievd it from:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-replaces-02.txt

--
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 daemon@ns.ietf.org  Wed May 15 18:47:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24691
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 18:47:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA08201
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 18:48:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07813;
	Wed, 15 May 2002 18:35:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07785
	for <sip@ns.ietf.org>; Wed, 15 May 2002 18:35:36 -0400 (EDT)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24349
	for <sip@ietf.org>; Wed, 15 May 2002 18:35:20 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4FMWSne025620;
	Wed, 15 May 2002 18:32:28 -0400 (EDT)
Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id K8ZHHFPM; Wed, 15 May 2002 18:35:03 -0400
Message-ID: <3CE2E296.6060007@dynamicsoft.com>
Date: Wed, 15 May 2002 18:35:02 -0400
From: Anders Kristensen <akristensen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org
Subject: Supported semantics [WAS: Re: [Sip] Revision of draft-willis-sip-path
 to version -07]
References: <000901c1fc31$b2c05230$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Dean Willis wrote:
>>    The UA should include the option tag "path" as a header 
>>vfield value
>>    in all Supported header fields, and should include a 
>>Supported header
>>    field in all requests.
>>
>>This make it sound like the path token is optional if the UA 
>>inserts a 
>>Supported header. I believe it's the case that a Supported 
>>header must 
>>always include the tokens for all supported extensions.
> 
> 
> Yes, this is definitely a slightly different usage of Supported. It's
> the closest thing we could come up with to a hinting mechanism, and
> probably deserves discussion in its own right. It made Robert Sparks
> hair stand on end until he thought about it for a while. But it's
> actually pretty cool.
> 
> Think about it -- someday we're going to have 1,000 extensions, so every
> Supported header is going to be like 20kB long. So the suggested
> semantic is that the UA include only those options it is willing to use
> for this transaction or any dialog resulting from it, rather than every
> possibe supported extension.

I think the reason the requirement is there is that if a proxy/UAS 
cannot tell from a Supported header whether the UAC supports a 
particular extension it cannot intelligently downgrade the service it 
provides - does it send a 420 in the hope that the UAC will resend with 
the extension token or does it proceed without the extension.

One idea that was floated at the time was to allow a special Supported 
token signaling that all supported extensions have been listed. But 
given that this is not what's in the current or previous specs, servers 
wouldn't be able to interpret absence of such a special token as 
guarantee that the UAC didn't send a complete Supported list anyway, so 
it wouldn't really help now.

Anders


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



From daemon@ns.ietf.org  Wed May 15 20:09:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26120
	for <sip-archive@odin.ietf.org>; Wed, 15 May 2002 20:09:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA11601
	for sip-archive@odin.ietf.org; Wed, 15 May 2002 20:09:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10603;
	Wed, 15 May 2002 19:48:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10572
	for <sip@ns.ietf.org>; Wed, 15 May 2002 19:48:07 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25679
	for <sip@ietf.org>; Wed, 15 May 2002 19:47:52 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4FNlhV14423
	for <sip@ietf.org>; Wed, 15 May 2002 18:47:43 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXXRVDY>; Wed, 15 May 2002 18:47:35 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B080@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Wed, 15 May 2002 18:47:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FC6A.E296C870"
Subject: [Sip] Comments on 3pcc
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

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

Hi All,

Additional comments/nits on the 3pcc :

1) Call Flow - Figure 7: ACK missing after (7)-the 200 OK to A.

2) Figure 11 uses the c=0 mid call - I assume that this is the "blackhole
SDP" (c= line has an IP address 0.0.0.0). The offer-answer draft allows the
use of this type of SDP only in the initial offer quote "However, it can be
useful in an initial offer when the offerer knows it wants to use a
particular set of media streams and formats, but doesn't know the addresses
and ports at the time of the offer." which is not the case here. Should we
consider having the controller sending the Called Party an INVITE with a
a=inactive SDP attribute for every media stream involved?

3) Figure 8 - is it valid for Party A to offer early media when the INVITE
came in with no media lines?? 

4) Fig 11: The RTP session (10) should be shown bi-directional.

5) Section 9.2 - Change "This is an instantiation of Flow II" to read "This
is an instantiation of Flow I". Remove the need for HTTP and have the Media
Server send BYE when its done.

6) Security question on section 11: Given that 3pcc will be used for things
like 'click-to-call, when I am browsing the web, how will I configure my UA
to have credentials of potentially arbitrary controllers on the Internet.
Using Certificates is definitely a better recommendation here.

7) General nits:
	* section 4.2 "generatea" to "generates"
	* section 4.3 "A thid flow" to "A third flow"
	* section 4.4 "manipuldations" to "manipulations"
	* section 6 "participant instead A call" to "participant instead. A
call"
	* section 8 "Third aty" to "Third party"



Regards,

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


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Comments on 3pcc</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2 FACE=3D"Courier New">Additional comments/nits on the =
3pcc :</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">1) Call Flow - Figure 7: ACK =
missing after (7)-the 200 OK to A.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">2) Figure 11 uses the c=3D0 mid =
call - I assume that this is the &quot;blackhole SDP&quot; (c=3D line =
has an IP address 0.0.0.0). The offer-answer draft allows the use of =
this type of SDP only in the initial offer quote &quot;However, it can =
be useful in an initial offer when the offerer knows it wants to use a =
particular set of media streams and formats, but doesn't know the =
addresses and ports at the time of the offer.&quot; which is not the =
case here. Should we consider having the controller sending the Called =
Party an INVITE with a a=3Dinactive SDP attribute for every media =
stream involved?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">3) Figure 8 - is it valid for =
Party A to offer early media when the INVITE came in with no media =
lines?? </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">4) Fig 11: The RTP session (10) =
should be shown bi-directional.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">5) Section 9.2 - Change =
&quot;This is an instantiation of Flow II&quot; to read &quot;This is =
an instantiation of Flow I&quot;. Remove the need for HTTP and have the =
Media Server send BYE when its done.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">6) Security question on section =
11: Given that 3pcc will be used for things like 'click-to-call, when I =
am browsing the web, how will I configure my UA to have credentials of =
potentially arbitrary controllers on the Internet. Using Certificates =
is definitely a better recommendation here.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">7) General nits:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">* section 4.2 &quot;generatea&quot; to =
&quot;generates&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">* section 4.3 &quot;A thid flow&quot; to &quot;A =
third flow&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">* section 4.4 &quot;manipuldations&quot; to =
&quot;manipulations&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">* section 6 &quot;participant instead A call&quot; =
to &quot;participant instead. A call&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">* section 8 &quot;Third aty&quot; to &quot;Third =
party&quot;</FONT>
</P>
<BR>
<BR>

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

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

</BODY>
</HTML>
------_=_NextPart_001_01C1FC6A.E296C870--

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



From daemon@optimus.ietf.org  Thu May 16 01:28:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05105
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 01:28:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA10599
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 01:28:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02216;
	Thu, 16 May 2002 01:01:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02187
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 01:01:09 -0400 (EDT)
Received: from mail.dascom.com.cn (IDENT:root@[211.100.13.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04591
	for <Sip@ietf.org>; Thu, 16 May 2002 01:00:51 -0400 (EDT)
Received: from yannote ([192.168.91.226])
	by mail.dascom.com.cn (8.9.3/8.9.3) with ESMTP id NAA29190;
	Thu, 16 May 2002 13:30:04 +0800
Date: Thu, 16 May 2002 12:59:26 +0800
From: Zhicheng Yan <yanzc@mail.dascom.com.cn>
To: Sip@ietf.org, Sip-implementors@cs.columbia.edu
Reply-To: yanzc@mail.dascom.com.cn
Organization: Dascom Technology LTD.(Beijing)
Message-Id: <20020516125745.1B82.YANZC@mail.dascom.com.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Mailer: Becky! ver. 2.05 (beta3)
Content-Transfer-Encoding: 8bit
Subject: [Sip] Anyone notices the problerm?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,Helpers:

I am developing SIP stack using JAIN.
But when testing, i found that too long a SIP Message sent out using UDP
will make itself truncated. It might be the limits of MTU, but how can I
extend the MTU (I am testing under Windows and Solaris, in Intranet
environment.)? Does JAIN support (or plan to support) such network
parameter adjust? 

Thank you all.

--
                                     Sincerely yours 
                                  Zhicheng Yan(ãÆÖ¾³É) 
========================================================================
Zhicheng Yan                
Dascom Technology, Beijing  
tel :+86-10-62961199-226    
fax: 86-10-62961527         
IM: MSN Messenger, .Net Messenger Service.
========================================================================



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



From daemon@optimus.ietf.org  Thu May 16 03:28:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16051
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 03:28:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA20515
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 03:28:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17324;
	Thu, 16 May 2002 03:03:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA17296
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 03:03:50 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15241
	for <sip@ietf.org>; Thu, 16 May 2002 03:03:33 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4G73k0E022698
	for <sip@ietf.org>; Thu, 16 May 2002 09:03:46 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4G73k9q001423
	for <sip@ietf.org>; Thu, 16 May 2002 10:03:46 +0300 (EET DST)
Message-ID: <3CE359D2.289E76ED@lmf.ericsson.se>
Date: Thu, 16 May 2002 10:03:46 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] URI headers
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Hi,

URI's may contain headers, using the "?" mechanism as defined in chapter
19.1.1.

The chapter says that the hname "body" indicates that the associated
hvalue is the message-body of the SIP request.

Should it be mentioned, that if "body" is used there MUST also be a
"Content-Type" header?

Regards,

Christer Holmberg
Ericsson Finland




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



From daemon@optimus.ietf.org  Thu May 16 04:16:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17188
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 04:16:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA24425
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 04:16:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21921;
	Thu, 16 May 2002 03:36:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21891
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 03:36:48 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16295
	for <sip@ietf.org>; Thu, 16 May 2002 03:36:18 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4G6ewY04998
	for <sip@ietf.org>; Thu, 16 May 2002 09:40:58 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5ae5109060ac158f25076@esvir05nok.ntc.nokia.com>;
 Thu, 16 May 2002 09:42:04 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 16 May 2002 09:42:04 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Thu, 16 May 2002 09:42:04 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED07@esebe013.NOE.Nokia.com>
Thread-Topic: [Sip] Message draft changes
Thread-Index: AcH7VXpjs4GewQeVSZmywGRc2fUdywBSbAXQ
To: <bcampbell@dynamicsoft.com>, <sip@ietf.org>
X-OriginalArrivalTime: 16 May 2002 06:42:04.0548 (UTC) FILETIME=[CA82A440:01C1FCA4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA21892
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

Comments inline.

> > > I submitted draft-ietf-sip-message-04 last week. This version
> > > contains a few
> > > AD requested changes, primarily in the area of congestion control.
> > > Specifically:
> > >
> > > 1) Added an applicability statement clarifying the difference
> > > between the
> > > pager and session models, and that this draft only defines
> > > the pager model.
> > >
> > > 2) Strengthened the congestion control section:
> > >
> > >    * 1300 byte hard limit for physical payload size for pager
> > > model. This
> > > applies to the actual payload only, not indirect content. 
> Fragmenting
> > > content across multiple requests is prohibited for pager model.
> >
> > I don't agree with this at all. This sort of hard limit really
> > hampers the whole IM application. The session mode and paging
> > mode IM are very different in nature. Session IM is clearly
> > conversational, whereas paging mode IM much more of a
> > "shoot-and-forget" type messaging. Now if the selection between
> > the two is not based on user preference and needs but on payload
> > size, I don't think this serves the IM users very well.
> >
> > Also, 1300 bytes seems awfully little, if I want to send
> > message/cpim with S/MIME protection.
> >
> 
> I understand your concern. The problem is, the IESG is very 
> concerned about
> the potential for congestion caused by MESSAGE. We initially 
> stated that, if
> your payload was over 1300 bytes, you must use a congestion-controlled
> transport. The SIP spec itself says that now, I think. The problem is,
> outside of a dialog, there is no way to ensure that no hop 
> will traverse
> UDP. So to allow larger payloads, we would have to solve that 
> problem first.
> We did not want to make MESSAGE dependent on a solution for 
> that problem.

Since it is totally possible to send the MESSAGE directly to the recipient (R-URI points to the interface address directly, not the AOR), doesn't the sender in this case have definite knowledge, that the hop will use TCP? The MUST strength forces the UA to *always* follow the fixed 1300 limit. 

I'm sure there are also other cases, where UDP hops will definitely not exist. I'm wondering if the congestion control could do away with some SHOULD based construct on the size limitation? The MUST really limits the features of IM, in my opinion.

> There is work underway to define a mechanism for indirect 
> content. I think
> we will have to use that for any sort of large content.

I'm aware of that work. The problem is that it is still in a concept level only. Even though it looks like a trivially solvable problem, discussions on the requirements in the interim meeting suggested that there are some tricky issues to it, too. I'm not buying this argument until there's at least a WG item for a solution.

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
> 

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



From daemon@optimus.ietf.org  Thu May 16 04:42:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17629
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 04:42:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA26246
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 04:42:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24883;
	Thu, 16 May 2002 04:23:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24845
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 04:23:22 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17400
	for <sip@ietf.org>; Thu, 16 May 2002 04:23:08 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4G8NF0E022342;
	Thu, 16 May 2002 10:23:15 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4G8NE9q006710;
	Thu, 16 May 2002 11:23:14 +0300 (EET DST)
Message-ID: <3CE36C71.7B160EA8@lmf.ericsson.se>
Date: Thu, 16 May 2002 11:23:13 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@lucent.com>
CC: sip <sip@ietf.org>, Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: Re: [Sip] Reason version 01
References: <3CE0E481.6DC961ED@lmf.ericsson.se> <3CE267A9.7030608@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Vijay,

Good point. I forgot completely about updating the references. 

I believe that Jonathan wants to wait for a while before advancing the
155 stuff to RFC (Jonathan, can you confirm this point?). But we have to
advance 3pcc and Reason together. 

However, I do not think we have any problem. The reason draft can speak
about 155 responses without referencing any RFC. It is enough that the
155 status code is registered wherever we are registering status codes
(is it already in IANA or we still have a temporary repository?).

Does anybiody see a problem with this approach?

thanks,

Gonzalo

"Vijay K. Gurbani" wrote:
> 
> Gonzalo Camarillo wrote:
> > Folks,
> >
> > I have just released version 01 of the Reason draft. Until it appears in
> > the archives, you can fetch it from:
> > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-reason-01.txt
> >
> > Only minor modifications has been done since version 00.
> 
> Gonzalo:
> 
> 155 provisional response has been excised from the UPDATE I-D; the
> Reason I-D has a now invalid reference which lists the UPDATE I-D for
> 155 responses.  Additionally, HERFP has also been excised from the
> UPDATE I-D, leaving it mainly as a media negotiation method before
> the dialog is established.
> 
> I believe I saw email from Jonathan on the WG list where he declared
> his intention to publish an extension to UPDATE, which lists the 155
> response I-D as well as HERFP.  I am wondering if we should define
> the 155 provisional response code and HERFP in the Reason I-D, since it
> depends on both as use cases.
> 
> Regards,
> 
> - vijay
> --
> Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
> Wireless Networks Group/Internet Software and Services
> Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
> Naperville, Illinois 60566     Voice: +1 630 224 0216

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@optimus.ietf.org  Thu May 16 09:35:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24360
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 09:35:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA12933
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 09:35:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11323;
	Thu, 16 May 2002 09:09:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA02572
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 06:39:28 -0400 (EDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19512
	for <Sip@ietf.org>; Thu, 16 May 2002 06:39:13 -0400 (EDT)
Received: from nist.gov (stinkbug.antd.nist.gov [129.6.55.9])
	by email.nist.gov (8.12.2/8.12.2) with ESMTP id g4GAdRab012483;
	Thu, 16 May 2002 06:39:27 -0400 (EDT)
Message-ID: <3CE38C5E.8090005@nist.gov>
Date: Thu, 16 May 2002 06:39:26 -0400
From: "M. Ranganathan" <mranga@nist.gov>
Reply-To: mranga@nist.gov
Organization: N.I.S.T. Advanced Networking Technologies Division
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: yanzc@mail.dascom.com.cn
CC: Sip@ietf.org, Sip-implementors@cs.columbia.edu
References: <20020516125745.1B82.YANZC@mail.dascom.com.cn>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Sip] Re: [Sip-implementors] Anyone notices the problerm?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Try using TCP transport. You can specify TCP transport using the
transport=tcp on the url parameters. The default is UDP.

Ranga.

Zhicheng Yan wrote:

>Hi,Helpers:
>
>I am developing SIP stack using JAIN.
>But when testing, i found that too long a SIP Message sent out using UDP
>will make itself truncated. It might be the limits of MTU, but how can I
>extend the MTU (I am testing under Windows and Solaris, in Intranet
>environment.)? Does JAIN support (or plan to support) such network
>parameter adjust? 
>
>Thank you all.
>
>--
>                                     Sincerely yours 
>                                  Zhicheng Yan(ãÆÖ¾³É) 
>========================================================================
>Zhicheng Yan                
>Dascom Technology, Beijing  
>tel :+86-10-62961199-226    
>fax: 86-10-62961527         
>IM: MSN Messenger, .Net Messenger Service.
>========================================================================
>
>
>_______________________________________________
>Sip-implementors mailing list
>Sip-implementors@cs.columbia.edu
>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

-- 

M. Ranganathan
N.I.S.T. Advanced Networking Technologies Division 
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899
Tel:301 975 3664; fax:301 590 0932

Advanced Networking Technologies for the people!





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



From daemon@optimus.ietf.org  Thu May 16 10:18:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25755
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 10:18:51 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA15071
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 10:19:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13546;
	Thu, 16 May 2002 09:48:19 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA13515
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 09:48:17 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24889
	for <sip@ietf.org>; Thu, 16 May 2002 09:48:00 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GDm1X89876;
	Thu, 16 May 2002 08:48:02 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Thu, 16 May 2002 08:47:58 -0500
Message-ID: <HNEOJECGFHIABDLENMMCGELPCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED07@esebe013.NOE.Nokia.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, May 16, 2002 1:42 AM
> To: bcampbell@dynamicsoft.com; sip@ietf.org
> Subject: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
>
[snip]

>
> > I understand your concern. The problem is, the IESG is very
> > concerned about
> > the potential for congestion caused by MESSAGE. We initially
> > stated that, if
> > your payload was over 1300 bytes, you must use a congestion-controlled
> > transport. The SIP spec itself says that now, I think. The problem is,
> > outside of a dialog, there is no way to ensure that no hop
> > will traverse
> > UDP. So to allow larger payloads, we would have to solve that
> > problem first.
> > We did not want to make MESSAGE dependent on a solution for
> > that problem.
>
> Since it is totally possible to send the MESSAGE directly to the
> recipient (R-URI points to the interface address directly, not
> the AOR), doesn't the sender in this case have definite
> knowledge, that the hop will use TCP? The MUST strength forces
> the UA to *always* follow the fixed 1300 limit.
>
> I'm sure there are also other cases, where UDP hops will
> definitely not exist. I'm wondering if the congestion control
> could do away with some SHOULD based construct on the size
> limitation? The MUST really limits the features of IM, in my opinion.

We had it as a SHOULD before, and were asked to change it. It might be
possible to change it to say you MUST NOT exceed 1300 bytes unless you have
affirmative knowledge that no hop along the way will use UDP. But that
limits you to some pretty trivial uses in the pager model.


>
> > There is work underway to define a mechanism for indirect
> > content. I think
> > we will have to use that for any sort of large content.
>
> I'm aware of that work. The problem is that it is still in a
> concept level only. Even though it looks like a trivially
> solvable problem, discussions on the requirements in the interim
> meeting suggested that there are some tricky issues to it, too.
> I'm not buying this argument until there's at least a WG item for
> a solution.

I agree it is not trivial, but it is doable. I think we are in process of
getting a wg item for this in SIMPLE. We _do_ have a wg item for message
sessions in SIMPLE, which would be another possible solution.


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


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



From daemon@optimus.ietf.org  Thu May 16 11:08:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27533
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 11:08:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA19148
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:08:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16828;
	Thu, 16 May 2002 10:47:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16797
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 10:47:07 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26667
	for <sip@ietf.org>; Thu, 16 May 2002 10:46:47 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4GElHk22566
	for <sip@ietf.org>; Thu, 16 May 2002 17:47:17 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5ae6cc7649ac158f2214f@esvir02nok.ntc.nokia.com>;
 Thu, 16 May 2002 17:46:55 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 16 May 2002 17:46:55 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Thu, 16 May 2002 17:46:55 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED0E@esebe013.NOE.Nokia.com>
Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Thread-Index: AcH84FFd0+Lqsdc8SWOJ39DvveOQRAABQFDQ
To: <bcampbell@dynamicsoft.com>, <sip@ietf.org>
X-OriginalArrivalTime: 16 May 2002 14:46:55.0771 (UTC) FILETIME=[863AFEB0:01C1FCE8]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA16798
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

Comments inline.

> > Since it is totally possible to send the MESSAGE directly to the
> > recipient (R-URI points to the interface address directly, not
> > the AOR), doesn't the sender in this case have definite
> > knowledge, that the hop will use TCP? The MUST strength forces
> > the UA to *always* follow the fixed 1300 limit.
> >
> > I'm sure there are also other cases, where UDP hops will
> > definitely not exist. I'm wondering if the congestion control
> > could do away with some SHOULD based construct on the size
> > limitation? The MUST really limits the features of IM, in 
> my opinion.
> 
> We had it as a SHOULD before, and were asked to change it. It might be
> possible to change it to say you MUST NOT exceed 1300 bytes 
> unless you have
> affirmative knowledge that no hop along the way will use UDP. But that
> limits you to some pretty trivial uses in the pager model.

I wish I had a piece of text to suggest that would satisfy this, but I don't. I understand that there may be a non-bis09 compatible proxy out there despite the suggestions made about the congestion control in the MESSAGE draft. But still, fixing a maximum size of 1300 bytes for IM seems to me, if you don't mind my saying ;), a hack. Sort of like the one that limited SMSs to be only 160 characters long...

> > > There is work underway to define a mechanism for indirect
> > > content. I think
> > > we will have to use that for any sort of large content.
> >
> > I'm aware of that work. The problem is that it is still in a
> > concept level only. Even though it looks like a trivially
> > solvable problem, discussions on the requirements in the interim
> > meeting suggested that there are some tricky issues to it, too.
> > I'm not buying this argument until there's at least a WG item for
> > a solution.
> 
> I agree it is not trivial, but it is doable. I think we are 
> in process of
> getting a wg item for this in SIMPLE. We _do_ have a wg item 
> for message
> sessions in SIMPLE, which would be another possible solution.

In my opinion, the message session won't work well enough. The user experience in the session model is inherently different to the paging model. Receiving an INVITE should indicate that there exists a desire to establish a conversation. Likewise, accepting the INVITE should indicate that the party is willing to commit to the conversation, however brief it may end up being. But if the reason for establishing the session was actually to circumvent some transport inefficiency, this user experience factor is lost.

Regards,
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 daemon@optimus.ietf.org  Thu May 16 11:27:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28363
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 11:27:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA20880
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:27:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17851;
	Thu, 16 May 2002 10:59:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17676
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 10:59:45 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27183
	for <sip@ietf.org>; Thu, 16 May 2002 10:59:29 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4GExmk29853
	for <sip@ietf.org>; Thu, 16 May 2002 17:59:49 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5ae6d7ecdbac158f23075@esvir03nok.nokia.com>;
 Thu, 16 May 2002 17:59:27 +0300
Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779);
	 Thu, 16 May 2002 17:59:27 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 16 May 2002 17:59:26 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] Message draft changes
Date: Thu, 16 May 2002 17:59:25 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791B8@esebe019.NOE.Nokia.com>
Thread-Topic: [Sip] Message draft changes
Thread-Index: AcH7VXmgI1Dz9YmIQ/K/dh0DjDky5wBk5NQw
To: <bcampbell@dynamicsoft.com>, <aki.niemi@nokia.com>, <sip@ietf.org>
X-OriginalArrivalTime: 16 May 2002 14:59:26.0355 (UTC) FILETIME=[459D0630:01C1FCEA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA17677
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

It seems to me that your limitation is on the assumption that Ethernet is the underlying Data Link layer. 

I admit some UDP implementations also limit the UDP datagram size to a smaller value than 64K. But as it says, its an implementation, and that's why the limitation should be an implementation issue depending on the underlying network, the API, etc. and not restricted by the protocol standard.

Regards,
Hisham


> -----Original Message-----
> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Tuesday, May 14, 2002 5:40 PM
> To: Niemi Aki (NET/Espoo); sip@ietf.org
> Subject: RE: [Sip] Message draft changes
> 
> 
> 
> 
> > -----Original Message-----
> > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> > Sent: Tuesday, May 14, 2002 4:54 AM
> > To: sip@ietf.org
> > Cc: bcampbell@dynamicsoft.com
> > Subject: RE: [Sip] Message draft changes
> >
> >
> > Hi Ben,
> >
> > > I submitted draft-ietf-sip-message-04 last week. This version
> > > contains a few
> > > AD requested changes, primarily in the area of congestion control.
> > > Specifically:
> > >
> > > 1) Added an applicability statement clarifying the difference
> > > between the
> > > pager and session models, and that this draft only defines
> > > the pager model.
> > >
> > > 2) Strengthened the congestion control section:
> > >
> > >    * 1300 byte hard limit for physical payload size for pager
> > > model. This
> > > applies to the actual payload only, not indirect content. 
> Fragmenting
> > > content across multiple requests is prohibited for pager model.
> >
> > I don't agree with this at all. This sort of hard limit really
> > hampers the whole IM application. The session mode and paging
> > mode IM are very different in nature. Session IM is clearly
> > conversational, whereas paging mode IM much more of a
> > "shoot-and-forget" type messaging. Now if the selection between
> > the two is not based on user preference and needs but on payload
> > size, I don't think this serves the IM users very well.
> >
> > Also, 1300 bytes seems awfully little, if I want to send
> > message/cpim with S/MIME protection.
> >
> 
> I understand your concern. The problem is, the IESG is very 
> concerned about
> the potential for congestion caused by MESSAGE. We initially 
> stated that, if
> your payload was over 1300 bytes, you must use a congestion-controlled
> transport. The SIP spec itself says that now, I think. The problem is,
> outside of a dialog, there is no way to ensure that no hop 
> will traverse
> UDP. So to allow larger payloads, we would have to solve that 
> problem first.
> We did not want to make MESSAGE dependent on a solution for 
> that problem.
> 
> There is work underway to define a mechanism for indirect 
> content. I think
> we will have to use that for any sort of large content.
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Thu May 16 11:28:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28452
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 11:28:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA21176
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:28:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18940;
	Thu, 16 May 2002 11:06:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18910
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 11:06:05 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27420
	for <sip@ietf.org>; Thu, 16 May 2002 11:05:49 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GF5sX96647;
	Thu, 16 May 2002 10:05:54 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Thu, 16 May 2002 10:05:51 -0500
Message-ID: <HNEOJECGFHIABDLENMMCCEMCCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED0E@esebe013.NOE.Nokia.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Thursday, May 16, 2002 9:47 AM
> To: bcampbell@dynamicsoft.com; sip@ietf.org
> Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
>
>

{snip}

>
> I wish I had a piece of text to suggest that would satisfy this,
> but I don't. I understand that there may be a non-bis09
> compatible proxy out there despite the suggestions made about the
> congestion control in the MESSAGE draft. But still, fixing a
> maximum size of 1300 bytes for IM seems to me, if you don't mind
> my saying ;), a hack. Sort of like the one that limited SMSs to
> be only 160 characters long...

I certainly don't mind you saying it :-).

The problem is not just pre-bis proxies, btw. If I understand correctly,
even a bis proxy can choose to switch to UDP if it cannot reach the next hop
via TCP. A general fix might lie there.

>
> In my opinion, the message session won't work well enough. The
> user experience in the session model is inherently different to
> the paging model. Receiving an INVITE should indicate that there
> exists a desire to establish a conversation. Likewise, accepting
> the INVITE should indicate that the party is willing to commit to
> the conversation, however brief it may end up being. But if the
> reason for establishing the session was actually to circumvent
> some transport inefficiency, this user experience factor is lost.

If we assume that client software directly exposes the difference between
page and session model as part of the user experience, I agree with you.
(Yahoo, for example, has an IM and conference model that are clearly
different user experiences.) But it is entirely possible to present a page
model user experience while still using a session model underneath. (I am
withholding judgement as to whether this is a good idea.)  Indeed, many
people appear to consider session vs. page mode selection as based on
content size and congestion issues rather than on user experience.

>
> Regards,
> 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 daemon@optimus.ietf.org  Thu May 16 11:32:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28653
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 11:32:26 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA21878
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:32:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19240;
	Thu, 16 May 2002 11:08:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19209
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 11:08:46 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27573
	for <sip@ietf.org>; Thu, 16 May 2002 11:08:31 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GF8fX96817;
	Thu, 16 May 2002 10:08:41 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: <hisham.khartabil@nokia.com>, <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: [Sip] Message draft changes
Date: Thu, 16 May 2002 10:08:37 -0500
Message-ID: <HNEOJECGFHIABDLENMMCAEMDCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB77791B8@esebe019.NOE.Nokia.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Actually, I pulled the number out of the bis-09, which says you SHOULD use
congestion control if your content-size is >1300. Clearly, that number
appears to be chosen there for the reasons you mention. I agree with your
statement, but I prefer to keep the number consistent between the message
draft and the SIP spec.

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Thursday, May 16, 2002 9:59 AM
> To: bcampbell@dynamicsoft.com; aki.niemi@nokia.com; sip@ietf.org
> Subject: RE: [Sip] Message draft changes
>
>
> It seems to me that your limitation is on the assumption that
> Ethernet is the underlying Data Link layer.
>
> I admit some UDP implementations also limit the UDP datagram size
> to a smaller value than 64K. But as it says, its an
> implementation, and that's why the limitation should be an
> implementation issue depending on the underlying network, the
> API, etc. and not restricted by the protocol standard.
>
> Regards,
> Hisham
>
>
> > -----Original Message-----
> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> > Sent: Tuesday, May 14, 2002 5:40 PM
> > To: Niemi Aki (NET/Espoo); sip@ietf.org
> > Subject: RE: [Sip] Message draft changes
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> > > Sent: Tuesday, May 14, 2002 4:54 AM
> > > To: sip@ietf.org
> > > Cc: bcampbell@dynamicsoft.com
> > > Subject: RE: [Sip] Message draft changes
> > >
> > >
> > > Hi Ben,
> > >
> > > > I submitted draft-ietf-sip-message-04 last week. This version
> > > > contains a few
> > > > AD requested changes, primarily in the area of congestion control.
> > > > Specifically:
> > > >
> > > > 1) Added an applicability statement clarifying the difference
> > > > between the
> > > > pager and session models, and that this draft only defines
> > > > the pager model.
> > > >
> > > > 2) Strengthened the congestion control section:
> > > >
> > > >    * 1300 byte hard limit for physical payload size for pager
> > > > model. This
> > > > applies to the actual payload only, not indirect content.
> > Fragmenting
> > > > content across multiple requests is prohibited for pager model.
> > >
> > > I don't agree with this at all. This sort of hard limit really
> > > hampers the whole IM application. The session mode and paging
> > > mode IM are very different in nature. Session IM is clearly
> > > conversational, whereas paging mode IM much more of a
> > > "shoot-and-forget" type messaging. Now if the selection between
> > > the two is not based on user preference and needs but on payload
> > > size, I don't think this serves the IM users very well.
> > >
> > > Also, 1300 bytes seems awfully little, if I want to send
> > > message/cpim with S/MIME protection.
> > >
> >
> > I understand your concern. The problem is, the IESG is very
> > concerned about
> > the potential for congestion caused by MESSAGE. We initially
> > stated that, if
> > your payload was over 1300 bytes, you must use a congestion-controlled
> > transport. The SIP spec itself says that now, I think. The problem is,
> > outside of a dialog, there is no way to ensure that no hop
> > will traverse
> > UDP. So to allow larger payloads, we would have to solve that
> > problem first.
> > We did not want to make MESSAGE dependent on a solution for
> > that problem.
> >
> > There is work underway to define a mechanism for indirect
> > content. I think
> > we will have to use that for any sort of large content.
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Thu May 16 11:32:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28687
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 11:32:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA21894
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 11:33:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19464;
	Thu, 16 May 2002 11:11:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA19435
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 11:11:01 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27677
	for <sip@ietf.org>; Thu, 16 May 2002 11:10:46 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GFBdYH011118;
	Thu, 16 May 2002 11:11:40 -0400 (EDT)
Message-ID: <3CE3CBCF.A051959F@dynamicsoft.com>
Date: Thu, 16 May 2002 11:10:07 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sriram Parameswar <sriramp@nortelnetworks.com>
CC: "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] Comments on 3pcc
References: <EF1056F8EB4ED511B8FB0002A56079D401E5B080@zrc2c014.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Thanks for your comments. Responses inline.

Sriram Parameswar wrote:
> 
> Hi All,
> 
> Additional comments/nits on the 3pcc :
> 
> 1) Call Flow - Figure 7: ACK missing after (7)-the 200 OK to A.

Fixed.

> 
> 2) Figure 11 uses the c=0 mid call - I assume that this is the
> "blackhole SDP" (c= line has an IP address 0.0.0.0). 

Yes. 

> The offer-answer
> draft allows the use of this type of SDP only in the initial offer quote
> "However, it can be useful in an initial offer when the offerer knows it
> wants to use a particular set of media streams and formats, but doesn't
> know the addresses and ports at the time of the offer." which is not the
> case here. Should we consider having the controller sending the Called
> Party an INVITE with a a=inactive SDP attribute for every media stream
> involved?

No, since it would still end up sending RTCP, which is not what you
want. c=0.0.0.0 is the right thing here. The text in offer/answer is not
normative; it doesn't forbid its use in other cases. 

> 
> 3) Figure 8 - is it valid for Party A to offer early media when the
> INVITE came in with no media lines??

It wants to use early media, but can't. Thats why it returns the 183
with no media lines. When the UPDATE comes, it will be able to provide
session information for the actual early media. 

> 
> 4) Fig 11: The RTP session (10) should be shown bi-directional.

Yeah, my tool doesn't do bidirectional arrows.... I'll use .....

> 
> 5) Section 9.2 - Change "This is an instantiation of Flow II" to read
> "This is an instantiation of Flow I".

Fixed.

> Remove the need for HTTP and have
> the Media Server send BYE when its done.

I made this change as well, as per my other note.

> 
> 6) Security question on section 11: Given that 3pcc will be used for
> things like 'click-to-call, when I am browsing the web, how will I
> configure my UA to have credentials of potentially arbitrary controllers
> on the Internet. Using Certificates is definitely a better
> recommendation here.

I must admit that the security considerations section is weak and needs
some more work. Generally, the problem is that anything where a third
party involved is inherently more complex. Add that to the fact that end
user authentication, even for first person calls, is quite hard, and its
a nasty problem.

It might make more sense to consider the problem as a few sub-cases:

Case A: For many applications, the controller and one of the parties in
the call are within the same administrative domain. A classic example is
click-to-dial. The controller and the customer service rep are both
within the domain of the company provided the c2d service. As such, it
is not unreasonable for the controller to actually possess a client cert
authenticating itself as sip:customer-service@company.com, which is the
same thing it would put into the From field of the INVITE to the end
user. No shared secrets are needed, and no special configuration at the
end user's machine. Thus, there is a pretty good story here. 

Case B: The controller is an independent entity from either of the
parties in the call. I agree its unreasonable to expect that the end
users will have shared secrets with the controller, but it depends on
the application. I think that ultimately, the identity work being
carried out right now might help here. Effectively, this is a case where
a trusted third party is trying to deliver a call to some user B, with
an identity it asserted (that of user A). In this case, the identity of
user A is not determined through sip authentication, but rather, through
the fact that this is a 3pcc call and the controller vouches for the
fact that the other party is who the controller asserts it to be.
Actually, I think this fits very nicely into the identity work. The best
I can do here, to avoid dependencies, is to speak generally about
asserted identities.

So, here is the new text I propose for the security considerations
section:

\section{Security Considerations}

\subsection{Identity}

The principal security consideration with third party call control is
identity. When the
controller initiates the call, what identity does it place in the From
field of the INVITE? The controller could indicate that the call is
from itself (From: sip:controller@company.com), but the call is really
from some user, and is just facilitated by the controller. This
impacts on how the call is authenticated by the end users.

There are many cases, and the right one depends on the application of
3pcc. In one common scenario, the controller is acting on behalf of
one of the participants in the call. A typical example is
click-to-dial, where the controller and the customer service
representative are run by the same administrative domain. Indeed, for
the purposes of identification, the controller can legitimately claim
to be the customer service representative. In this scenario, it would
be appropriate for the INVITE to the end user to contain a From field
identifying the customer service rep, and authenticate the request
using S/MIME signed by the key of the customer service rep (which is
held by the controller). 

In other situations, there is no real relationship between the
controller and the participants in the call. In these situations,
ideally the controller would have a means to assert that the call is
from a particular identity (which could be one of the participants, or
even a third party, depending on the application), and to validate
that assertion with a signature using the key of the controller.

\subsection{End-to-End Encryption and Integrity}

With third party call control, the controller is actually one of the
participants as far as the SIP dialog is concerened. Therefore,
encryption and integrity of the SIP messages, as provided by S/MIME,
will occur between participants and the controller, rather than
directly between participants. 



> 
> 7) General nits:
>         * section 4.2 "generatea" to "generates"
>         * section 4.3 "A thid flow" to "A third flow"
>         * section 4.4 "manipuldations" to "manipulations"
>         * section 6 "participant instead A call" to "participant
> instead. A call"
>         * section 8 "Third aty" to "Third party"

All fixed.

Thanks,
Jonathan R.


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

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



From daemon@optimus.ietf.org  Thu May 16 13:38:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03501
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 13:38:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA01556
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 13:38:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA29900;
	Thu, 16 May 2002 13:17:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA25482
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 12:19:33 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00753
	for <sip@ietf.org>; Thu, 16 May 2002 12:19:17 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA22623
	for <sip@ietf.org>; Thu, 16 May 2002 18:19:18 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id SAA05522
	for <sip@ietf.org>; Thu, 16 May 2002 18:19:31 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <K94LMV43>; Thu, 16 May 2002 18:19:31 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6FDF3DE@mchh161e>
From: Heil Franca Marcelo  ICM N PG U ID A 2
	 <Marcelo.HeilFranca@icn.siemens.de>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Thu, 16 May 2002 18:19:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] WG: Message draft changes
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hello,

I think that the issue of limiting the size of MESSAGE payload is not only
related to transport protocols for congestion control but also concerns, as
partially mentioned in the draft, the use of the siganlling infrastructure
to transfer instant messaging traffic. 
It can be discussed whether 1300 bytes is the right value, but a size
limitation is required. This also enforces congestion control when used in
conjunction with the other rules stated in the draft (not fragment contents
across multiple MESSAGE requests and not initiate a new MESSAGE transaction
as long as there is one pending).

Regards,
Marcelo

-----Original Message-----
From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
Sent: 16 May 2002 16:59
To: bcampbell@dynamicsoft.com; aki.niemi@nokia.com; sip@ietf.org
Subject: RE: [Sip] Message draft changes


It seems to me that your limitation is on the assumption that Ethernet is
the underlying Data Link layer. 

I admit some UDP implementations also limit the UDP datagram size to a
smaller value than 64K. But as it says, its an implementation, and that's
why the limitation should be an implementation issue depending on the
underlying network, the API, etc. and not restricted by the protocol
standard.

Regards,
Hisham


> -----Original Message-----
> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Tuesday, May 14, 2002 5:40 PM
> To: Niemi Aki (NET/Espoo); sip@ietf.org
> Subject: RE: [Sip] Message draft changes
> 
> 
> 
> 
> > -----Original Message-----
> > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> > Sent: Tuesday, May 14, 2002 4:54 AM
> > To: sip@ietf.org
> > Cc: bcampbell@dynamicsoft.com
> > Subject: RE: [Sip] Message draft changes
> >
> >
> > Hi Ben,
> >
> > > I submitted draft-ietf-sip-message-04 last week. This version
> > > contains a few
> > > AD requested changes, primarily in the area of congestion control.
> > > Specifically:
> > >
> > > 1) Added an applicability statement clarifying the difference
> > > between the
> > > pager and session models, and that this draft only defines
> > > the pager model.
> > >
> > > 2) Strengthened the congestion control section:
> > >
> > >    * 1300 byte hard limit for physical payload size for pager
> > > model. This
> > > applies to the actual payload only, not indirect content. 
> Fragmenting
> > > content across multiple requests is prohibited for pager model.
> >
> > I don't agree with this at all. This sort of hard limit really
> > hampers the whole IM application. The session mode and paging
> > mode IM are very different in nature. Session IM is clearly
> > conversational, whereas paging mode IM much more of a
> > "shoot-and-forget" type messaging. Now if the selection between
> > the two is not based on user preference and needs but on payload
> > size, I don't think this serves the IM users very well.
> >
> > Also, 1300 bytes seems awfully little, if I want to send
> > message/cpim with S/MIME protection.
> >
> 
> I understand your concern. The problem is, the IESG is very 
> concerned about
> the potential for congestion caused by MESSAGE. We initially 
> stated that, if
> your payload was over 1300 bytes, you must use a congestion-controlled
> transport. The SIP spec itself says that now, I think. The problem is,
> outside of a dialog, there is no way to ensure that no hop 
> will traverse
> UDP. So to allow larger payloads, we would have to solve that 
> problem first.
> We did not want to make MESSAGE dependent on a solution for 
> that problem.
> 
> There is work underway to define a mechanism for indirect 
> content. I think
> we will have to use that for any sort of large content.
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Thu May 16 14:17:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04980
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 14:17:55 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA04368
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 14:18:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02097;
	Thu, 16 May 2002 13:50:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02068
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 13:50:14 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03883
	for <sip@ietf.org>; Thu, 16 May 2002 13:50:00 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4GHnbd03063;
	Thu, 16 May 2002 12:49:37 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Anders Kristensen'" <akristensen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: RE: Supported semantics [WAS: Re: [Sip] Revision of draft-willis-sip-path to version -07]
Date: Thu, 16 May 2002 12:49:06 -0500
Message-ID: <006701c1fd01$f96d5090$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CE2E296.6060007@dynamicsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Anders wrote:
> Dean Willis wrote:
> >>    The UA should include the option tag "path" as a header
> >>vfield value
> >>    in all Supported header fields, and should include a 
> >>Supported header
> >>    field in all requests.
> >>
> >>This make it sound like the path token is optional if the UA
> >>inserts a 
> >>Supported header. I believe it's the case that a Supported 
> >>header must 
> >>always include the tokens for all supported extensions.
> > 
> > 
> > Yes, this is definitely a slightly different usage of 
> Supported. It's 
> > the closest thing we could come up with to a hinting mechanism, and 
> > probably deserves discussion in its own right. It made 
> Robert Sparks 
> > hair stand on end until he thought about it for a while. But it's 
> > actually pretty cool.
> > 
> > Think about it -- someday we're going to have 1,000 extensions, so 
> > every Supported header is going to be like 20kB long. So 
> the suggested 
> > semantic is that the UA include only those options it is willing to 
> > use for this transaction or any dialog resulting from it, 
> rather than 
> > every possibe supported extension.
> 
> I think the reason the requirement is there is that if a proxy/UAS 
> cannot tell from a Supported header whether the UAC supports a 
> particular extension it cannot intelligently downgrade the service it 
> provides - does it send a 420 in the hope that the UAC will 
> resend with 
> the extension token or does it proceed without the extension.

The assumption has to be that the UA is unwilling to (read WILL NOT) use
extensions other than those listed, so the proxy simply proceeds as if
the extension is not supported by the UA -- if it's REQUIRED, reject the
request.
 
> One idea that was floated at the time was to allow a special 
> Supported 
> token signaling that all supported extensions have been listed. But 
> given that this is not what's in the current or previous 
> specs, servers 
> wouldn't be able to interpret absence of such a special token as 
> guarantee that the UAC didn't send a complete Supported list 
> anyway, so 
> it wouldn't really help now.

I believe  my proposal requires no changes whatsoever to proxy logic. If
the proxy requires that a UA support a particular extension not listed,
it 420s. If it doesn't, it forwards (optionally adding a Requires). If
the UA just happens to offer a different set of options on another
transaction, the proxy doesn't really care -- the decisions always
happen on a per-transaction basis anyhow.

--
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 daemon@optimus.ietf.org  Thu May 16 15:01:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06586
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 15:01:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA07122
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:02:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05635;
	Thu, 16 May 2002 14:35:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05606
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 14:35:26 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05629
	for <sip@ietf.org>; Thu, 16 May 2002 14:35:11 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GIaKYH011303;
	Thu, 16 May 2002 14:36:22 -0400 (EDT)
Message-ID: <3CE3FBC9.2806605@dynamicsoft.com>
Date: Thu, 16 May 2002 14:34:49 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "P. Vijay" <pvijay@mchsi.com>
CC: sip@ietf.org
Subject: Re: [Sip] UPDATE and Expires
References: <000801c1f85e$378ebc40$6601a8c0@mchsi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Far as I can tell, the spec already specifies a fix to this problem. Its
timer C in the proxies. When an INVITE traverses a proxy, it sets timer
C to some value 3 minutes or greater, determined by the service
provider. Each time a provisional response is received, the timer is
reset. This allows a UAS to extend the timer. However, in the case
outlined by Brian, I assume that the UAS doesn't want to explicitly
extend the timer. Therefore, after 3 minutes, the timer will fire in a
proxy. According to section 16.8, unless the provider wishes to extend
the timer, the proxy will generate a CANCEL. This will cause the UAS to
cease ringing and generate a 487. That will also terminate the
transaction at the UAC, assuming its still alive. It will also clean up
state in any proxies along the path.

Thus, Brian's problem was due to a proxy which has not implemented timer
C as specified in bis.

-Jonathan R.

"P. Vijay" wrote:
> 
>         I think the solution is either a policy decision implemented at
> the SIP
> service provider level or a basic addition to the
> INVITE/TRYING/RINGING/OK/ACK message flow.  I am for using INVITE
> expires
> and letting the SP decide on (a) using its internal timer or expires,
> whichever is lesser and (b) resetting the timer when it receives an
> UPDATE.
> The call is cleared when the timer expires. This is based on reasons
> given
> below.
> 
>         In the traditional telehpony world, answer timers (the time
> between start
> of ringing and a valid answer) are (typically) set to avoid holding up
> bandwidth for unbillable calls.  This is especially true for inband
> signalling.  Even for out-of-band signaling, ISDN/ISUP, etc., the
> protocol
> DEFINES timers between the state when the called party acknowledges
> (180)
> the call (INVITE) and the state when a valid answer (200)is received.
> If
> the timer expires, then the call is cleared by the caller.  In reality,
> the
> call is cleared by the switch that handles the caller's CPE (even that
> is a
> gross simplification, but it will do).  In fact, the tandems with the
> lowest
> configured answer timers clear the call and propagate the clearing in
> both
> directions.  The important point here is that this behaviour is a
> codification of what is seen as good policy (i.e, don't waste resources,
> etc.), not necessarily essential for call control.
> 
>         In this case, the problem arose because the caller (UAC) died
> after sending
> INVITE and UAS did not detect the client death.  Can that not be handled
> at
> the trasport (tcp timers, heartbeats, etc.) and clear the call?
> 
>         In the case where the UAC is alive and keeps waiting for the
> 200, either
> UAS or the called (UAS/UAC) could clear the call as described above.
> 
>         I have seen answer timers cause problems in regular telephony
> services, so
> putting in mandatory timers (a-la ISDN or ISUP) would be a hindrance.
> However, SP's need policies, preferably encoded in RFC's, that allow for
> both call terminations on ring-no-answer and possibly extending the
> timer
> (e.g. via UPDATE).
> 
>         SIP does not have to codify an answer timer, although it may be
> a good idea
> to do provide some guidance.  Also, the timer can be exchanged in SDP,
> except it would need to be sent in TRYING or RINGING. In the absence of
> a
> timer, the matter of detecting a crashed device needs to addressed.
> 
> --Vijay--
> 
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
> > Of Rosen,
> > Brian
> > Sent: Friday, May 10, 2002 12:38 PM
> > To: 'Prabhas Sinha'; Bert Culpepper; sip@ietf.org
> > Subject: RE: [Sip] UPDATE and Expires
> >
> >
> > Pick up your phone and dial a number without a message system.
> > It will ring quite a while (not forever).  Mine waits
> > multiple minutes.
> > The problem with making assumptions on how long to time out is
> > that it's the user, not the UAC, that knows how long is long enough.
> > What do you want to do, have him type in a timer length?
> > Yes, you can use a timer on either end, but it needs to be on the
> > order of minutes, not seconds, and it does not express the wishes
> > of either the caller or the callee.  It's the system designer (or
> > administrator if it's programmable)'s idea of how long is enough.
> >
> > Note that in SIP, there are no messages passing while you are
> > waiting.  Of course, I want there to be a few (UPDATE with
> > Expire), just so that the called party knows the calling party
> > still thinks it ought to be ringing.  Then the expiry can be
> > on the order of seconds.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Prabhas Sinha [mailto:prsinha@unity.ncsu.edu]
> > > Sent: Friday, May 10, 2002 1:06 PM
> > > To: Bert Culpepper; 'Rosen, Brian'; sip@ietf.org
> > > Subject: Re: [Sip] UPDATE and Expires
> > >
> > >
> > > > I would think the caller will have an idea of how long
> > > he/she wants to
> > > wait
> > > > for answer, and set the value of the Expires header
> > > accordingly in the
> > > > INVITE request.  However, if the caller's UA doesn't
> > > support this and it
> > > > crashes, then I believe it's an implementation issue for
> > > the UAS.  Or when
> > > > the callee answers the call, current defined protocol
> > > behavior (no ACK
> > > > received) will suffice here.
> > > >
> > > > Regards,
> > > > Bert
> > > >
> > >
> > > on the contrary, why dont dont we support it from the callee
> > > end like PSTN ?
> > > If the callee is not at his seat, then why to hold up the
> > > resources until
> > > caller's "Expire" header?
> > > Think of the performance when there are millions of users
> > > hitting this bend
> > > and blocking the resources for more than actually needed.
> > > If I know that I am not available then I can configure my UAC
> > > somehow to
> > > inform the caller on the very first ring that
> > > I am not able to pick up the phone. I am just thinking it on
> > > the lines of
> > > PSTN operation -- its not the caller who decides how long the
> > > call should be
> > > presented
> > > but its the callee's phone which handles it. If the current
> > bis doesnt
> > > support it then we might wanna bring in a minor extension to
> > > handle this.
> > >
> > > Does it sound ok ?
> > >
> > > Prabhas
> > >
> > >
> > >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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

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

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



From daemon@optimus.ietf.org  Thu May 16 15:45:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08669
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 15:45:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA08782
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:46:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07850;
	Thu, 16 May 2002 15:24:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07819
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 15:24:41 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07452
	for <sip@ietf.org>; Thu, 16 May 2002 15:24:27 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJPcYH011747;
	Thu, 16 May 2002 15:25:38 -0400 (EDT)
Message-ID: <3CE40757.27745562@dynamicsoft.com>
Date: Thu, 16 May 2002 15:24:07 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@lucent.com>
CC: SIP LIST <sip@ietf.org>
Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling
References: <3CD949D5.7080907@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

inline.

"Vijay K. Gurbani" wrote:
> 
> Since most people were busy with the interim SIP WG meeting, I did not
> hear from anyone on the list, I will send this out again...
> 
> Some comments on -09bis on Timers C, B, and spiraling:
> 
> 1) In SIP, proxies can fork either in serial or in parallel.  Consider
>     serial forking for this discussion.  Normally, in the presence of
>     multiple Contact headers to an address-of-record, a proxy will sort
>     the Contacts based on their q value and fork serially to each
>     Contact.  If Contact 1 did not elicit a final response within a
>     certain time, Contact 2 will be tried, and so on.  Problem is,
>     what exactly is the time for a proxy to give up on the current
>     Contact and try the next one?
> 
>     Reading -09bis, it appears that timer C can serve this function.

Timer C is meant more for cleanup, not as a way to perform services.

The timer value to use when moving amongst contacts depends heavily on
the application. I suspect that normally there would be some logic
guiding the sequential operation, rather than just based on the q
values. As such, I think this is best left as implementation specific.

>     But the initial value of timer C is too high (3 minutes, and it is
>     a MUST to set it to at least 3 mins), so that will not work.
> Another
>     possible candidate is the transaction timeout; if a proxy allows a
>     client transaction to continue (T1*64 seconds = 32 seconds) until it
>     times out, the time between trying the next Contact (32 seconds) is
>     too large for the caller to keep holding.  So, this does not work
>     either.
> 
>     Should -09bis provide some guidance on timers to use in proxy cores
>     if serial forking is being used and > 1 Contact header is present,
>     or should this be left upto the implementer?

Left to implementor.

> 
> 2) Timer B controls transaction timeouts in INVITE client trans-
>     actions.  The state diagram in Figure 5 is silent on what to
>     do if Timer B fires while control is in "Proceeding" state; i.e.
>     received a 180, but no final response.  The correct behavior
>     should be to sent a CANCEL and enter "Terminated" state.

No. Timer C used to be in here, specifying the amount of time the caller
"lets the phone ring". However, this really only needs to be specified
for proxies (which is whats in bis). For the UAC, how long to let the
phone ring is entirely application specific. 

> 
> 3) Regarding finding the spiraled R-R on responses in order to
>     modify it (section 16.7, step 8), won't it be the case that
>     the first R-R in a response corresponds to the inner-most
>     spiral?  Since the inner-most spiral will generate the first
>     response, can't we just get the first R-R header on a response
>     in order to modify it?

Thats true for the first loop through, but not the second (or
subsequent) loops through. Remember, record-routes are not popped as you
traverse through it. 

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

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



From daemon@optimus.ietf.org  Thu May 16 15:46:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08703
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 15:46:35 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA08812
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:46:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07530;
	Thu, 16 May 2002 15:17:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07499
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 15:17:51 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07142
	for <sip@ietf.org>; Thu, 16 May 2002 15:17:36 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJIfYH011714;
	Thu, 16 May 2002 15:18:41 -0400 (EDT)
Message-ID: <3CE405B6.68310065@dynamicsoft.com>
Date: Thu, 16 May 2002 15:17:10 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: aki.niemi@nokia.com, sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
References: <HNEOJECGFHIABDLENMMCCEMCCIAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> 
> > -----Original Message-----
> > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> > Sent: Thursday, May 16, 2002 9:47 AM
> > To: bcampbell@dynamicsoft.com; sip@ietf.org
> > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> > changes)
> >
> >
> 
> {snip}
> 
> >
> > I wish I had a piece of text to suggest that would satisfy this,
> > but I don't. I understand that there may be a non-bis09
> > compatible proxy out there despite the suggestions made about the
> > congestion control in the MESSAGE draft. But still, fixing a
> > maximum size of 1300 bytes for IM seems to me, if you don't mind
> > my saying ;), a hack. Sort of like the one that limited SMSs to
> > be only 160 characters long...
> 
> I certainly don't mind you saying it :-).
> 
> The problem is not just pre-bis proxies, btw. If I understand correctly,
> even a bis proxy can choose to switch to UDP if it cannot reach the next
> hop
> via TCP. A general fix might lie there.

Right. We did that to handle backwards compatibility with UAs that are
pre-bis and don't support TCP.

I must admit that I also dislike the artificial limit. But, I've been
thinking about this more, and I think a different perspective on it
helps. Generally, page mode allows arbitrarily large content to be sent.
However, after a certain size is exceeded, the protocol moves to a model
of indirect content instead of directly sending it. I would argue that
the reason for this is not so much congestion control, but consent. If
you are sending an IM to a user on a wireless phone, you really don't
want to send them that 300meg movie unless they really want it. Content
indirection allows the recipient the ability to decide whether they want
the content now or later. This makes a lot of sense for content of
varied types and of larger sized content.

So, overall, an IM system that provides page mode can support messages
of any size, it just requires content indirection to support the larger
stuff.

So, all of that means we need this little content indirection thing
pretty badly, after all. My sense from the interim meeting was that the
requirements work was actually in pretty good shape, and we were ready
to get moving on the implementation, which is also pretty
straightforward. It really belongs in sip not simple, though. I hope our
ADs would be gracious about getting a work item into sip whose purpose
is to greatly enhance the story on consent and congestion control.... ;)

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Thu May 16 15:55:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09114
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 15:55:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA09004
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 15:55:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08204;
	Thu, 16 May 2002 15:30:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08160
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 15:30:23 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07813
	for <sip@ietf.org>; Thu, 16 May 2002 15:30:09 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJVGYH011751;
	Thu, 16 May 2002 15:31:17 -0400 (EDT)
Message-ID: <3CE408AA.6E1417BF@dynamicsoft.com>
Date: Thu, 16 May 2002 15:29:46 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
CC: sip@ietf.org
Subject: Re: [Sip] Possible ABNF bug
References: <3CE2B67C.11209B4@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

inline.

Christer Holmberg wrote:
> 
> Hi,
> 
> Bis-09 says that the "@" character is not allowed in the SIP-URI (or
> SIPS-URI) if the userinfo part of the URI is empty (eg "@sip.world.com"
> is not allowed).
> 
> However, the ABNF says:
> 
> SIP-URI          =  "sip:" [ userinfo "@" ] hostport  uri-parameters [
> headers ]
> 
> userinfo         =  [ user / telephone-subscriber [ ":" password ]]
> 
> Now, the first line (defines SIP-URI) does indicate that userinfo,
> together with @, is optional in the URI.
> 
> The second line (defines userinfo), however, indicates that user,
> telephone-subscriber and password ALSO are optional for userinfo, which
> to my understanding means that an empty value IS a valid value for
> userinfo.

This is an error.

> 
> I think the correct syntax should be:
> 
> userinfo         =  ( user / telephone-subscriber [ ":" password ])
> 
> Also, does the syntax above password to be used together with user, or
> only together with telephone-subscriber? IF so, then I guess the correct
> syntax shall be:
> 
> userinfo         =  ( user / telephone-subscriber) [ ":" password ]

Correct. 

-Jonathan R.


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

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



From daemon@optimus.ietf.org  Thu May 16 15:59:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09271
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 15:59:49 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA09097
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 16:00:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08624;
	Thu, 16 May 2002 15:37:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08594
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 15:37:45 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08232
	for <sip@ietf.org>; Thu, 16 May 2002 15:37:30 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4GJceYH011760;
	Thu, 16 May 2002 15:38:40 -0400 (EDT)
Message-ID: <3CE40A66.5CD536D8@dynamicsoft.com>
Date: Thu, 16 May 2002 15:37:10 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org
Subject: Re: [Sip] Message draft changes
References: <HNEOJECGFHIABDLENMMCAEMDCIAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> 
> Actually, I pulled the number out of the bis-09, which says you SHOULD
> use
> congestion control if your content-size is >1300. Clearly, that number
> appears to be chosen there for the reasons you mention. I agree with
> your
> statement, but I prefer to keep the number consistent between the
> message
> draft and the SIP spec.


Actually, the spec uses 1300 only when the path MTU is not known:

If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU 3572
is unknown, the request MUST be sent using TCP.


-Jonathan R.

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

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



From daemon@optimus.ietf.org  Thu May 16 16:39:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10249
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 16:39:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA11532
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 16:39:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09770;
	Thu, 16 May 2002 16:11:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09738
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 16:11:43 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09483
	for <sip@ietf.org>; Thu, 16 May 2002 16:11:27 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4GKB3d04104;
	Thu, 16 May 2002 15:11:04 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        <bernhard.honeisen@nokia.com>
Date: Thu, 16 May 2002 15:10:31 -0500
Message-ID: <007f01c1fd15$bc104d10$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Revised: draft-willis-sip-svcrtdisco to -04
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Bernie and I have revised the Service Route Discovery draft. This was
pretty much just a language cleanup with a few points clarified in
REGISTER processing if there is a stored P-Service-Route. We also
attempted to globally change the term "header" to "header field" to be
consistent with the language in RFC 3261.

The latest version is available at:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-04.htm
l
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-04.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-04.xml

And should be available soon on the IETF site.


Please note that this draft is in "Expert Review", closing very soon . .
 .

--
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 daemon@optimus.ietf.org  Thu May 16 16:57:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10722
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 16:57:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA12002
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 16:57:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10165;
	Thu, 16 May 2002 16:21:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10133
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 16:21:46 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09701
	for <sip@ietf.org>; Thu, 16 May 2002 16:21:31 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4GKL6d04229;
	Thu, 16 May 2002 15:21:07 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "3GPP_TSG_CN_WG1" <3GPP_TSG_CN_WG1@LIST.ETSI.FR>,
        <bernhard.honeisen@nokia.com>
Date: Thu, 16 May 2002 15:20:35 -0500
Message-ID: <008b01c1fd17$23743ce0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_008C_01C1FCED.3A9E34E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Subject: [Sip] Alert to Version Number Issue:  I-D ACTION:draft-willis-sip-path-06.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

This is a multi-part message in MIME format.

------=_NextPart_000_008C_01C1FCED.3A9E34E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


Somehow I got out of synch with the Internet-Drafts list, and my path
-07 got announced as -06 and my -06 didn't get announced at all. Oops.

Way forward: I have reset the softarmor site to match IETF. The
"unannounced" version -06 is in the morgue area as -06a. The version
currently posted is officially version -06, and has been amended to
match.

A new version -07 containing final changes should be forthcoming, so the
whole thing becomes only a matter of historical interest anyhow.

--
Dean



-----Original Message-----
From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us] On
Behalf Of Internet-Drafts@ietf.org
Sent: Wednesday, May 15, 2002 6:12 AM
To: IETF-Announce:
Cc: sip@ietf.org
Subject: I-D ACTION:draft-willis-sip-path-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: SIP Extension for Registering Non-Adjacent
Contacts
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-path-06.txt
	Pages		: 17
	Date		: 14-May-02
	
The REGISTER function is used in a SIP system primarily to associate a
temporary contact address with an address-of-record.  This contact is
generally in the form of a URI, such as Contact:
<sip:alice@pc33.atlanta.com> and is generally dynamic and associated
with the IP address or hostname of the SIP UA.  The problem is that
network topology may be that there are one or more SIP proxies between
the UA and the registrar, such that any request travelling from the
user's home network to the registered UA must traverse these proxies.
The REGISTER method does not give us a mechanism to discover and record
this sequence of proxies in the registrar for future use.  This document
defines an extension header field, 'Path' which provides such a
mechanism.

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

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

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

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


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

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

------=_NextPart_000_008C_01C1FCED.3A9E34E0
Content-Type: Message/External-body;
	name="ATT00137.dat"
Content-Disposition: attachment;
	filename="ATT00137.dat"
Content-Transfer-Encoding: 7bit

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

ENCODING mime
FILE /internet-drafts/draft-willis-sip-path-06.txt

------=_NextPart_000_008C_01C1FCED.3A9E34E0
Content-Type: Message/External-body;
	name="draft-willis-sip-path-06.txt"
Content-Disposition: attachment;
	filename="draft-willis-sip-path-06.txt"
Content-Transfer-Encoding: 7bit

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

------=_NextPart_000_008C_01C1FCED.3A9E34E0--


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



From daemon@optimus.ietf.org  Thu May 16 18:17:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12240
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 18:17:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA15499
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 18:17:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14477;
	Thu, 16 May 2002 17:46:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14446
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 17:46:24 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11757
	for <sip@ietf.org>; Thu, 16 May 2002 17:46:08 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4GLkGX29582;
	Thu, 16 May 2002 16:46:16 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <hisham.khartabil@nokia.com>, <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: [Sip] Message draft changes
Date: Thu, 16 May 2002 16:46:09 -0500
Message-ID: <HNEOJECGFHIABDLENMMCOENCCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CE40A66.5CD536D8@dynamicsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, May 16, 2002 2:37 PM
> To: Ben Campbell
> Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org
> Subject: Re: [Sip] Message draft changes
>
>
>
>
> Ben Campbell wrote:
> >
> > Actually, I pulled the number out of the bis-09, which says you SHOULD
> > use
> > congestion control if your content-size is >1300. Clearly, that number
> > appears to be chosen there for the reasons you mention. I agree with
> > your
> > statement, but I prefer to keep the number consistent between the
> > message
> > draft and the SIP spec.
>
>
> Actually, the spec uses 1300 only when the path MTU is not known:
>
> If a request is within 200 bytes of the path MTU, or if it is larger
> than 1300 bytes and the path MTU 3572
> is unknown, the request MUST be sent using TCP.
>
>

But, unless the UAC sending a MESSAGE request has only one hop, it is very
unlikely that the UAC can know the MTU for each hop. I can add text handles
the case for when you _do_ know the full path MTU--but I don't think that
situation will occur very often in the pager model.

Thanks!

Ben.


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



From daemon@optimus.ietf.org  Thu May 16 18:27:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12387
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 18:27:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA15731
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 18:27:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15157;
	Thu, 16 May 2002 18:01:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA15126
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 18:01:27 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12006
	for <sip@ietf.org>; Thu, 16 May 2002 18:01:11 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4GM0so00724;
	Thu, 16 May 2002 18:00:54 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA24270; Thu, 16 May 2002 17:00:53 -0500 (CDT)
Message-ID: <3CE42BED.3070109@lucent.com>
Date: Thu, 16 May 2002 17:00:13 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: SIP LIST <sip@ietf.org>
Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling
References: <3CD949D5.7080907@lucent.com> <3CE40757.27745562@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan:

vkg>2) Timer B controls transaction timeouts in INVITE client trans-
vkg>    actions.  The state diagram in Figure 5 is silent on what to
vkg>    do if Timer B fires while control is in "Proceeding" state; i.e.
vkg>    received a 180, but no final response.  The correct behavior
vkg>    should be to sent a CANCEL and enter "Terminated" state.

jdr> No. Timer C used to be in here, specifying the amount of time the
jdr> caller "lets the phone ring". However, this really only needs to be
jdr> specified for proxies (which is whats in bis). For the UAC, how
jdr> long to let the phone ring is entirely application specific.

Hmmm, so what happens in the following case:

UAC: INVITE sip:rep@aa.business
      Expires: 30

UAS: 182 Queued 5 minutes waiting time
[after 1/2 minute]
UAS: 182 Queued 4.5 minutes waiting time

After 30 seconds, the UAC will tear the transaction down since it never
got a final response; it got provisional responses which made proxies
increase their Timer C so they were fine.  But what about the UAC?
Looking at Figure 5, it seems that UAC will also benefit from a
dynamic transaction timeout window.  Furthermore, why set Timer B in
the "Calling" state?  If UDP is being used, we will know on the second
retx that a UAS does not exist (if the socket is bind()'ed to the UAS --
funny, this is missing from -09bis).  If TCP (or TLS, or I believe even
SCTP) is being used, the connection will fail right away.  So, a
transport error is bound to occur in the "Calling" state if a UAS does
not exist.  Is it possible to set timer B in the "Proceeding" state and
initalize it to the value of the Expires header (if present, T1*64 if
not) and then dynamically updated on provisionals, just like proxies?

For that matter, consider the above call flow for a UAS.  The spec now
dictates (in Section 13.3.1) that if the INVITE contained an Expires
header, then the UAS should generate a 487 after the time in Expires
expires.  So based on this interpretation, should the UAS at aa.business
even accept the session since it knows that there is no way a final
response will be generated in 30 seconds and there is no way it can get
the UAC to extend the expiration time?

vkg> Should -09bis provide some guidance on timers to use in proxy cores
vkg> if serial forking is being used and > 1 Contact header is present,
vkg> or should this be left upto the implementer?

jdr> The timer value to use when moving amongst contacts depends heavily 
jdr> on the application. I suspect that normally there would be some
jdr> logic guiding the sequential operation, rather than just based on
jdr> the q values. As such, I think this is best left as implementation
jdr> specific.

I still believe that the spec will not go wrong if it provided some
guidance.  For instance, most people are tuned to picking up their
phone before 4 rings since after that it kicks over to answering
machines or voice mail servers.  4 rings is about 20 seconds.  Maybe
20 seconds is a good default for a UAC branch to be tried in case
serial forking.

vkg>3) Regarding finding the spiraled R-R on responses in order to
vkg>    modify it (section 16.7, step 8), won't it be the case that
vkg>    the first R-R in a response corresponds to the inner-most
vkg>    spiral?  Since the inner-most spiral will generate the first
vkg>    response, can't we just get the first R-R header on a response
vkg>    in order to modify it?

jdr> Thats true for the first loop through, but not the second (or
jdr> subsequent) loops through. Remember, record-routes are not popped
jdr> as you traverse through it.

Yes, of course; you are absolutely right. I conveniently forgot that
part.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216


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



From daemon@optimus.ietf.org  Thu May 16 18:57:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13245
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 18:57:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA17279
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 18:57:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16680;
	Thu, 16 May 2002 18:35:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA16649
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 18:35:47 -0400 (EDT)
Received: from web11607.mail.yahoo.com (web11607.mail.yahoo.com [216.136.172.59])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12658
	for <sip@ietf.org>; Thu, 16 May 2002 18:35:31 -0400 (EDT)
Message-ID: <20020516223546.72165.qmail@web11607.mail.yahoo.com>
Received: from [207.46.137.8] by web11607.mail.yahoo.com via HTTP; Thu, 16 May 2002 15:35:46 PDT
Date: Thu, 16 May 2002 15:35:46 -0700 (PDT)
From: Sean Olson <seancolson@yahoo.com>
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Ben Campbell <bcampbell@dynamicsoft.com>
Cc: aki.niemi@nokia.com, sip@ietf.org
In-Reply-To: <3CE405B6.68310065@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

The consent piece is an interesting adjunct to the
content indirection requirements. I already allude
to the fact that you need to be able to negotiate
support / demand for such a mechanism. 

Do we need to express explicit policy about when
content indirection should be used?

/sean

--- Jonathan Rosenberg <jdrosen@dynamicsoft.com>
wrote:
> 
> 
> Ben Campbell wrote:
> > 
> > > -----Original Message-----
> > > From: aki.niemi@nokia.com
> [mailto:aki.niemi@nokia.com]
> > > Sent: Thursday, May 16, 2002 9:47 AM
> > > To: bcampbell@dynamicsoft.com; sip@ietf.org
> > > Subject: RE: MESSAGE size limitations (Was: RE:
> [Sip] Message draft
> > > changes)
> > >
> > >
> > 
> > {snip}
> > 
> > >
> > > I wish I had a piece of text to suggest that
> would satisfy this,
> > > but I don't. I understand that there may be a
> non-bis09
> > > compatible proxy out there despite the
> suggestions made about the
> > > congestion control in the MESSAGE draft. But
> still, fixing a
> > > maximum size of 1300 bytes for IM seems to me,
> if you don't mind
> > > my saying ;), a hack. Sort of like the one that
> limited SMSs to
> > > be only 160 characters long...
> > 
> > I certainly don't mind you saying it :-).
> > 
> > The problem is not just pre-bis proxies, btw. If I
> understand correctly,
> > even a bis proxy can choose to switch to UDP if it
> cannot reach the next
> > hop
> > via TCP. A general fix might lie there.
> 
> Right. We did that to handle backwards compatibility
> with UAs that are
> pre-bis and don't support TCP.
> 
> I must admit that I also dislike the artificial
> limit. But, I've been
> thinking about this more, and I think a different
> perspective on it
> helps. Generally, page mode allows arbitrarily large
> content to be sent.
> However, after a certain size is exceeded, the
> protocol moves to a model
> of indirect content instead of directly sending it.
> I would argue that
> the reason for this is not so much congestion
> control, but consent. If
> you are sending an IM to a user on a wireless phone,
> you really don't
> want to send them that 300meg movie unless they
> really want it. Content
> indirection allows the recipient the ability to
> decide whether they want
> the content now or later. This makes a lot of sense
> for content of
> varied types and of larger sized content.
> 
> So, overall, an IM system that provides page mode
> can support messages
> of any size, it just requires content indirection to
> support the larger
> stuff.
> 
> So, all of that means we need this little content
> indirection thing
> pretty badly, after all. My sense from the interim
> meeting was that the
> requirements work was actually in pretty good shape,
> and we were ready
> to get moving on the implementation, which is also
> pretty
> straightforward. It really belongs in sip not
> simple, though. I hope our
> ADs would be gracious about getting a work item into
> sip whose purpose
> is to greatly enhance the story on consent and
> congestion control.... ;)
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle
> Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East
> Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973)
> 952-5050
> http://www.jdrosen.net                  PH:  (973)
> 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
> Protocol
> Use sip-implementors@cs.columbia.edu for questions
> on current sip
> Use sipping@ietf.org for new developments on the
> application of sip


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.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 daemon@optimus.ietf.org  Thu May 16 19:16:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13628
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 19:16:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA18208
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 19:16:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17255;
	Thu, 16 May 2002 18:56:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17208
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 18:56:41 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13214
	for <sip@ietf.org>; Thu, 16 May 2002 18:56:25 -0400 (EDT)
Received: from there (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4GMtad05293;
	Thu, 16 May 2002 17:55:36 -0500
Message-Id: <200205162255.g4GMtad05293@bdsl.66.12.12.130.gte.net>
Content-Type: text/plain;
  charset="iso-8859-1"
From: Dean Willis <dean.willis@softarmor.com>
To: Anders Kristensen <akristensen@dynamicsoft.com>
Subject: Re: [Sip] Revision of draft-willis-sip-path to version -07
Date: Thu, 16 May 2002 17:55:35 -0500
X-Mailer: KMail [version 1.3.2]
Cc: sip@ietf.org
References: <01cb01c1fb77$429f2310$133fed0c@C1893415A> <3CE17F78.4050006@dynamicsoft.com>
In-Reply-To: <3CE17F78.4050006@dynamicsoft.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

On Tuesday 14 May 2002 04:19 pm, Anders Kristensen wrote:
> Hi Dean,
>
> You're still missing a couple:
>
> Line 190 (txt version): "reuqest"

fixed 

> Line 253: "vfield"

fixed 

> Other nits...
>
> Line 46: Does not compute: "The problem is that network topology may
> be that..."

restructured to: 

"The problem is that network topology may have one  or more SIP proxies 
between the UA and the registrar, such that any request travelling 
fromt he user's home network to the registered UA must traverse these 
proxies."

"
> Line 139: is "service proxy" an established term? Why not just
> "proxy".

Switched to "home proxy" and added the definition:
"a proxy serving as the terminal point for routing an 
address-of-record".


> Line 141: is "transited" really a real word?

yes.

>
> Line 147: "The proposed Path extension header field...". When
> becoming RFC it's no longer a proposal.

deleted.

> Line 172:
>
>     2.  The same set of intervening proxies MUST be visited by
> requests between a home service proxy and the UA.  That is, the proxy
> route between the home service proxy and the UA is the exact reverse
> of the proxy route between the UA and its registrar.
>
> As the draft points out later, this is not, strictly speaking, a
> condition for applicability.  One might end up with a subset of teh
> path travelled by the REGISTER and also, a proxy might insert
> addresses other than its own on the Path.

rephrased as:

"The same intermediate proxies or a set of proxies known to the 
intermediate proxies must be traversed, in reverse order, by requests 
sent through a home service proxy to the UA. In the simplest form, the 
route between the home service proxy and the UA is the exact inverse of 
the route between the UA and the route between the UA and the registrar"

> Line 198:
>
>     The primary difference between Path and Record-Route is that Path
>     applies to REGISTER and 200 OK responses to REGISTER. 
> Record-Route doesn't, and can't be defined in REGISTER for reasons of
> backward compatibility.
>
> I'd say the more important difference is that Record-Route applies to
> the dialog being set by the request it's used in whereas Path is used
> to establish a route for subsequent requests.

rephrased to:
"The difference between Path and Record-Route is that Path applies toR 
EGISTER and 200 OK responses to REGISTER. Record-Route doesn't, and 
can't be defined in REGISTER for reasons of backward compatibility. 
Furthermore, the vector established by Record-Route applies only to 
requests within the dialog that established that Record-Route, whereas 
the vector established by Path applies to future dialogs."

--
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 daemon@optimus.ietf.org  Thu May 16 21:07:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16206
	for <sip-archive@odin.ietf.org>; Thu, 16 May 2002 21:07:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA24042
	for sip-archive@odin.ietf.org; Thu, 16 May 2002 21:07:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22855;
	Thu, 16 May 2002 20:37:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA22823
	for <sip@optimus.ietf.org>; Thu, 16 May 2002 20:37:24 -0400 (EDT)
Received: from web12306.mail.yahoo.com (web12306.mail.yahoo.com [216.136.173.104])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15741
	for <sip@ietf.org>; Thu, 16 May 2002 20:37:09 -0400 (EDT)
Message-ID: <20020517003722.69951.qmail@web12306.mail.yahoo.com>
Received: from [64.121.72.77] by web12306.mail.yahoo.com via HTTP; Thu, 16 May 2002 17:37:22 PDT
Date: Thu, 16 May 2002 17:37:22 -0700 (PDT)
From: Natasha Varshney <natasha_varshney@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1723336866-1021595842=:68776"
Subject: [Sip] (no subject)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--0-1723336866-1021595842=:68776
Content-Type: text/plain; charset=us-ascii


Hi All,

I am doing a research project on SIP security  and privacy considerations.All I  found was the working papers on the subject.Iam looking for some technical papers if available.If anyone can help...

Thanks



---------------------------------
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
--0-1723336866-1021595842=:68776
Content-Type: text/html; charset=us-ascii

<P>Hi All,</P>
<P>I am doing a research project on SIP security&nbsp; and privacy considerations.All&nbsp;I &nbsp;found was the working papers on the subject.Iam looking for some technical papers if available.If anyone can help...</P>
<P>Thanks</P><p><br><hr size=1><b>Do You Yahoo!?</b><br>
<a href="http://rd.yahoo.com/welcome/*http://launch.yahoo.com">LAUNCH</a> - Your Yahoo! Music Experience
--0-1723336866-1021595842=:68776--

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



From daemon@optimus.ietf.org  Fri May 17 05:12:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06313
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 05:12:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA25336
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 05:12:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22768;
	Fri, 17 May 2002 04:31:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22710
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 04:30:58 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05644
	for <sip@ietf.org>; Fri, 17 May 2002 04:30:43 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4H8Uos7014917;
	Fri, 17 May 2002 10:30:51 +0200 (MEST)
Received: from lmf.ericsson.se (3OQK900K04BAB3K.lmf.ericsson.se [131.160.30.77])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4H8Uo9q020013;
	Fri, 17 May 2002 11:30:50 +0300 (EET DST)
Message-ID: <3CE4BFBC.5C7FD554@lmf.ericsson.se>
Date: Fri, 17 May 2002 11:30:52 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org
Subject: Re: [Sip] Possible ABNF bug
References: <3CE2B67C.11209B4@lmf.ericsson.se> <3CE408AA.6E1417BF@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Hi,

> > Bis-09 says that the "@" character is not allowed in the SIP-URI (or
> > SIPS-URI) if the userinfo part of the URI is empty (eg "@sip.world.com"
> > is not allowed).
> >
> > However, the ABNF says:
> >
> > SIP-URI          =  "sip:" [ userinfo "@" ] hostport  uri-parameters [
> > headers ]
> >
> > userinfo         =  [ user / telephone-subscriber [ ":" password ]]
> >
> > Now, the first line (defines SIP-URI) does indicate that userinfo,
> > together with @, is optional in the URI.
> >
> > The second line (defines userinfo), however, indicates that user,
> > telephone-subscriber and password ALSO are optional for userinfo, which
> > to my understanding means that an empty value IS a valid value for
> > userinfo.
>
> This is an error.
>
> >
> > I think the correct syntax should be:
> >
> > userinfo         =  ( user / telephone-subscriber [ ":" password ])
> >
> > Also, does the syntax above password to be used together with user, or
> > only together with telephone-subscriber? IF so, then I guess the correct
> > syntax shall be:
> >
> > userinfo         =  ( user / telephone-subscriber) [ ":" password ]
>
> Correct.

Then, if we "continue" the syntax, it says:

user             =  *( unreserved / escaped / user-unreserved )

So, even if userinfo must contain user (or telephone-subscriber) this still
allows an empty value for user, which again allows an empty value for
userinfo...

So, I guess the correct syntax for user would be:

user             = 1*( unreserved / escaped / user-unreserved )

(If userinfo contains telephone-subscriber we don't have this problem, since
telephone-subscriber always must contain some characters).

Regards,

Christer Holmberg
Ericsson Finland




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



From daemon@optimus.ietf.org  Fri May 17 06:57:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07646
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 06:57:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA29359
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 06:57:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA27013;
	Fri, 17 May 2002 05:58:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26982
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 05:58:49 -0400 (EDT)
Received: from MHPA8R1C (proxy8.netz.sbs.de [192.35.17.27])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06887
	for <sip@ietf.org>; Fri, 17 May 2002 05:58:34 -0400 (EDT)
From: "Salva Rey Calatayud" <salreyca@teleco.upv.es>
To: sip@ietf.org
Date: Wed, 17 May 2000 12:08:53 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Reply-to: salreyca@teleco.upv.es
Message-ID: <39228BD5.13877.1515E3BE@localhost>
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.12cDE)
X-SMTP-Server: PostCast Server 1.0.0
Content-Transfer-Encoding: 7BIT
Subject: [Sip] via header
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

Hi,

	I have a doubt regarding how the Via header is completed at 
the transport layer. 

	Should the transport indicated in the sent-protocol parameter 
be modified, if the request was solicited to be sent on UDP, and 
the transport layer decided to send it on TCP?

	if not, what's the purpose of indicating UDP by the transaction 
layer?

thanks
Salva


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



From daemon@optimus.ietf.org  Fri May 17 07:46:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09307
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 07:46:51 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA01665
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 07:47:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00536;
	Fri, 17 May 2002 07:26:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00504
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 07:26:26 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08445;
	Fri, 17 May 2002 07:26:08 -0400 (EDT)
Message-Id: <200205171126.HAA08445@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 17 May 2002 07:26:08 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-digest-aka-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: HTTP Digest Authentication Using AKA
	Author(s)	: A. Niemi, J. Arkko, V. Torvinen
	Filename	: draft-ietf-sip-digest-aka-02.txt
	Pages		: 18
	Date		: 16-May-02
	
The Hypertext Transfer Protocol (HTTP) Authentication Framework
includes two authentication schemes: Basic and Digest.  Both schemes
employ a shared secret based mechanism for access authentication.
The Authentication and Key Agreement (AKA) mechanism performs user
authentication and session key distribution in Universal Mobile
Telecommunications System (UMTS) networks.  AKA is a challenge-
response based mechanism that uses symmetric cryptography.  This memo
specifies an AKA based one-time password generation mechanism for
HTTP Digest access authentication.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 17 07:53:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09482
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 07:53:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA01746
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 07:53:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00574;
	Fri, 17 May 2002 07:26:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA00540
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 07:26:29 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08461;
	Fri, 17 May 2002 07:26:14 -0400 (EDT)
Message-Id: <200205171126.HAA08461@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 17 May 2002 07:26:13 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-replaces-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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 Session Inititation Protocol (SIP)
	Author(s)	: B. Biggs, R. Dean, R. Mahy
	Filename	: draft-ietf-sip-replaces-02.txt
	Pages		: 17
	Date		: 16-May-02
	
This document defines a new header for use with SIP multi-party
applications and call control.  The Replaces header is used to
logically replace an existing SIP dialog with a new SIP dialog.  This
primitive can be used to enable a variety of features, for example:
'Attended Transfer' and 'Retrieve from Call Park'.  Note that
definition of these example features is non-normative.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 17 11:52:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18274
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 11:52:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14328
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 11:52:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13368;
	Fri, 17 May 2002 11:31:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13337
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 11:31:52 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17620
	for <sip@ietf.org>; Fri, 17 May 2002 11:31:35 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFWVYH012633;
	Fri, 17 May 2002 11:32:32 -0400 (EDT)
Message-ID: <3CE52234.E6B387CD@dynamicsoft.com>
Date: Fri, 17 May 2002 11:31:00 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <seancolson@yahoo.com>
CC: Ben Campbell <bcampbell@dynamicsoft.com>, aki.niemi@nokia.com,
        sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
References: <20020516223546.72165.qmail@web11607.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Sean Olson wrote:
> 
> The consent piece is an interesting adjunct to the
> content indirection requirements. I already allude
> to the fact that you need to be able to negotiate
> support / demand for such a mechanism.
> 
> Do we need to express explicit policy about when
> content indirection should be used?

What I was saying is that the page mode spec DEFINES that policy
explicitly - anything over 1300 bytes means indirection.

-Jonathan R.


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

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



From daemon@optimus.ietf.org  Fri May 17 12:03:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18988
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 12:03:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA16639
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:03:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13648;
	Fri, 17 May 2002 11:38:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13549
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 11:38:09 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17767
	for <sip@ietf.org>; Fri, 17 May 2002 11:37:53 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFd4YH012636;
	Fri, 17 May 2002 11:39:05 -0400 (EDT)
Message-ID: <3CE523BE.B75B8BDC@dynamicsoft.com>
Date: Fri, 17 May 2002 11:37:34 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Vijay K. Gurbani" <vkg@lucent.com>
CC: SIP LIST <sip@ietf.org>
Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling
References: <3CE42BED.3070109@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



"Vijay K. Gurbani" wrote:
> 
> Jonathan:
> 
> vkg>2) Timer B controls transaction timeouts in INVITE client trans-
> vkg>    actions.  The state diagram in Figure 5 is silent on what to
> vkg>    do if Timer B fires while control is in "Proceeding" state; i.e.
> vkg>    received a 180, but no final response.  The correct behavior
> vkg>    should be to sent a CANCEL and enter "Terminated" state.
> 
> jdr> No. Timer C used to be in here, specifying the amount of time the
> jdr> caller "lets the phone ring". However, this really only needs to be
> jdr> specified for proxies (which is whats in bis). For the UAC, how
> jdr> long to let the phone ring is entirely application specific.
> 
> Hmmm, so what happens in the following case:
> 
> UAC: INVITE sip:rep@aa.business
>       Expires: 30
> 
> UAS: 182 Queued 5 minutes waiting time
> [after 1/2 minute]
> UAS: 182 Queued 4.5 minutes waiting time
> 
> After 30 seconds, the UAC will tear the transaction down since it never
> got a final response; it got provisional responses which made proxies
> increase their Timer C so they were fine.  But what about the UAC?

It will probably cancel after 30 seconds. I think this is the right
thing. A phone shouldn't be putting Expires in the INVITE unless it
really means it. Ultimately, its a policy issue here. The UAC has
expressed a policy, and the UAS has asked for more time. Who wins? I
say, the UAC wins, since its the one that is making the call. The
current mechanism reflects that, and you should insert Expires headers
only if thats what you want.

> Looking at Figure 5, it seems that UAC will also benefit from a
> dynamic transaction timeout window.  Furthermore, why set Timer B in
> the "Calling" state?  If UDP is being used, we will know on the second
> retx that a UAS does not exist (if the socket is bind()'ed to the UAS --
> funny, this is missing from -09bis).  If TCP (or TLS, or I believe even
> SCTP) is being used, the connection will fail right away.  So, a
> transport error is bound to occur in the "Calling" state if a UAS does
> not exist.  Is it possible to set timer B in the "Proceeding" state and
> initalize it to the value of the Expires header (if present, T1*64 if
> not) and then dynamically updated on provisionals, just like proxies?

I'm lost. Timer B handles time outs because of no response whatsoever.

> 
> For that matter, consider the above call flow for a UAS.  The spec now
> dictates (in Section 13.3.1) that if the INVITE contained an Expires
> header, then the UAS should generate a 487 after the time in Expires
> expires.  So based on this interpretation, should the UAS at aa.business
> even accept the session since it knows that there is no way a final
> response will be generated in 30 seconds and there is no way it can get
> the UAC to extend the expiration time?

It can do whatever it wants. I would be inclined to play a prompt that
says "your call won't be answered within the expiration time you've
specified. Please specify a longer time". Phones shouldn't be
arbitrarily be putting Expires in the INVITEs like that.

> 
> vkg> Should -09bis provide some guidance on timers to use in proxy cores
> vkg> if serial forking is being used and > 1 Contact header is present,
> vkg> or should this be left upto the implementer?
> 
> jdr> The timer value to use when moving amongst contacts depends heavily
> 
> jdr> on the application. I suspect that normally there would be some
> jdr> logic guiding the sequential operation, rather than just based on
> jdr> the q values. As such, I think this is best left as implementation
> jdr> specific.
> 
> I still believe that the spec will not go wrong if it provided some
> guidance.  For instance, most people are tuned to picking up their
> phone before 4 rings since after that it kicks over to answering
> machines or voice mail servers.  4 rings is about 20 seconds.  Maybe
> 20 seconds is a good default for a UAC branch to be tried in case
> serial forking.

It depends on the app; going to voicemail is one thing, doing a hunt
across a group of customer service reps is another thing. Both are
sequential fork, but both use different timers. I don't see the need to
overspecify this.

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Fri May 17 12:04:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19051
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 12:04:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA16799
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:05:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13872;
	Fri, 17 May 2002 11:41:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13841
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 11:41:08 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17834
	for <sip@ietf.org>; Fri, 17 May 2002 11:40:51 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFg3YH012643;
	Fri, 17 May 2002 11:42:03 -0400 (EDT)
Message-ID: <3CE5246E.74AA4210@dynamicsoft.com>
Date: Fri, 17 May 2002 11:40:30 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org
Subject: Re: [Sip] Message draft changes
References: <HNEOJECGFHIABDLENMMCOENCCIAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > Sent: Thursday, May 16, 2002 2:37 PM
> > To: Ben Campbell
> > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org
> > Subject: Re: [Sip] Message draft changes
> >
> >
> >
> >
> > Ben Campbell wrote:
> > >
> > > Actually, I pulled the number out of the bis-09, which says you
> SHOULD
> > > use
> > > congestion control if your content-size is >1300. Clearly, that
> number
> > > appears to be chosen there for the reasons you mention. I agree with
> > > your
> > > statement, but I prefer to keep the number consistent between the
> > > message
> > > draft and the SIP spec.
> >
> >
> > Actually, the spec uses 1300 only when the path MTU is not known:
> >
> > If a request is within 200 bytes of the path MTU, or if it is larger
> > than 1300 bytes and the path MTU 3572
> > is unknown, the request MUST be sent using TCP.
> >
> >
> 
> But, unless the UAC sending a MESSAGE request has only one hop, it is
> very
> unlikely that the UAC can know the MTU for each hop. I can add text
> handles
> the case for when you _do_ know the full path MTU--but I don't think
> that
> situation will occur very often in the pager model.

Careful here! Path and hop mean different things to folks at layer 3 and
at the app layer. The Path MTU refers to the smallest MTU along each
router hop from the IP source to the IP destination. For SIP, that is
just a single "hop" from the UAC to a proxy, say. Each SIP "hop"
(between UAC and proxy, or proxy to proxy) will have a different path
MTU, and could conceivably make a different transport decision based on
that. 

-Jonathan R.


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

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



From daemon@optimus.ietf.org  Fri May 17 12:10:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19243
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 12:10:35 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA16959
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:10:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14062;
	Fri, 17 May 2002 11:43:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14030
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 11:43:41 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17888
	for <sip@ietf.org>; Fri, 17 May 2002 11:43:25 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4HFidYH012826;
	Fri, 17 May 2002 11:44:40 -0400 (EDT)
Message-ID: <3CE5250A.4FFF01B0@dynamicsoft.com>
Date: Fri, 17 May 2002 11:43:06 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
CC: sip@ietf.org
Subject: Re: [Sip] Possible ABNF bug
References: <3CE4BFBC.5C7FD554@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

inline.

Christer Holmberg wrote:
> 
> Hi,
> 
> > > Bis-09 says that the "@" character is not allowed in the SIP-URI (or
> > > SIPS-URI) if the userinfo part of the URI is empty (eg
> "@sip.world.com"
> > > is not allowed).
> > >
> > > However, the ABNF says:
> > >
> > > SIP-URI          =  "sip:" [ userinfo "@" ] hostport  uri-parameters
> [
> > > headers ]
> > >
> > > userinfo         =  [ user / telephone-subscriber [ ":" password ]]
> > >
> > > Now, the first line (defines SIP-URI) does indicate that userinfo,
> > > together with @, is optional in the URI.
> > >
> > > The second line (defines userinfo), however, indicates that user,
> > > telephone-subscriber and password ALSO are optional for userinfo,
> which
> > > to my understanding means that an empty value IS a valid value for
> > > userinfo.
> >
> > This is an error.
> >
> > >
> > > I think the correct syntax should be:
> > >
> > > userinfo         =  ( user / telephone-subscriber [ ":" password ])
> > >
> > > Also, does the syntax above password to be used together with user,
> or
> > > only together with telephone-subscriber? IF so, then I guess the
> correct
> > > syntax shall be:
> > >
> > > userinfo         =  ( user / telephone-subscriber) [ ":" password ]
> >
> > Correct.
> 
> Then, if we "continue" the syntax, it says:
> 
> user             =  *( unreserved / escaped / user-unreserved )
> 
> So, even if userinfo must contain user (or telephone-subscriber) this
> still
> allows an empty value for user, which again allows an empty value for
> userinfo...
> 
> So, I guess the correct syntax for user would be:
> 
> user             = 1*( unreserved / escaped / user-unreserved )
> 
> (If userinfo contains telephone-subscriber we don't have this problem,
> since
> telephone-subscriber always must contain some characters).

Right again.

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Fri May 17 12:22:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19647
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 12:22:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA17426
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:22:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14382;
	Fri, 17 May 2002 11:53:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14351
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 11:53:03 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18304
	for <sip@ietf.org>; Fri, 17 May 2002 11:52:47 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4HFqOHs029079;
	Fri, 17 May 2002 08:52:24 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABR48415;
	Fri, 17 May 2002 08:49:21 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA01773; Fri, 17 May 2002 08:52:23 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15589.10039.127865.917811@thomasm-u1.cisco.com>
Date: Fri, 17 May 2002 08:52:23 -0700 (PDT)
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Sean Olson <seancolson@yahoo.com>,
        Ben Campbell <bcampbell@dynamicsoft.com>, aki.niemi@nokia.com,
        sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
In-Reply-To: <3CE52234.E6B387CD@dynamicsoft.com>
References: <20020516223546.72165.qmail@web11607.mail.yahoo.com>
	<3CE52234.E6B387CD@dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
 > 
 > 
 > Sean Olson wrote:
 > > 
 > > The consent piece is an interesting adjunct to the
 > > content indirection requirements. I already allude
 > > to the fact that you need to be able to negotiate
 > > support / demand for such a mechanism.
 > > 
 > > Do we need to express explicit policy about when
 > > content indirection should be used?
 > 
 > What I was saying is that the page mode spec DEFINES that policy
 > explicitly - anything over 1300 bytes means indirection.


Jonathan,

While I like the spirit of your proposal, I wonder
if it's going to run into operational problems.
Client's don't typically run web servers
(especially on some well known OSen). Also: some
cable MSO's filter port 80 to kill home web
servers. That means that they'd have to find and
upload that data to a willing web server. For
long-lived data that's not unreasonable, but for
short term/transient data that seems like a pretty
big burden.

When we discussed this ages ago it was in the
context of inlining jpeg mug shots and the like.
However if the context is IM, I'm not so sure
again. 

	   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 daemon@optimus.ietf.org  Fri May 17 12:24:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19670
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 12:24:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA17451
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 12:24:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14527;
	Fri, 17 May 2002 11:55:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14498
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 11:55:34 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18404
	for <sip@ietf.org>; Fri, 17 May 2002 11:55:13 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4HFt4X03762;
	Fri, 17 May 2002 10:55:05 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <hisham.khartabil@nokia.com>, <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: [Sip] Message draft changes
Date: Fri, 17 May 2002 10:54:56 -0500
Message-ID: <HNEOJECGFHIABDLENMMCMENPCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3CE5246E.74AA4210@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, May 17, 2002 10:41 AM
> To: Ben Campbell
> Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org
> Subject: Re: [Sip] Message draft changes
>
>
>
>
> Ben Campbell wrote:
> >
> > > -----Original Message-----
> > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> > > Sent: Thursday, May 16, 2002 2:37 PM
> > > To: Ben Campbell
> > > Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org
> > > Subject: Re: [Sip] Message draft changes
> > >
> > >
> > >
> > >
> > > Ben Campbell wrote:
> > > >
> > > > Actually, I pulled the number out of the bis-09, which says you
> > SHOULD
> > > > use
> > > > congestion control if your content-size is >1300. Clearly, that
> > number
> > > > appears to be chosen there for the reasons you mention. I agree with
> > > > your
> > > > statement, but I prefer to keep the number consistent between the
> > > > message
> > > > draft and the SIP spec.
> > >
> > >
> > > Actually, the spec uses 1300 only when the path MTU is not known:
> > >
> > > If a request is within 200 bytes of the path MTU, or if it is larger
> > > than 1300 bytes and the path MTU 3572
> > > is unknown, the request MUST be sent using TCP.
> > >
> > >
> >
> > But, unless the UAC sending a MESSAGE request has only one hop, it is
> > very
> > unlikely that the UAC can know the MTU for each hop. I can add text
> > handles
> > the case for when you _do_ know the full path MTU--but I don't think
> > that
> > situation will occur very often in the pager model.
>
> Careful here! Path and hop mean different things to folks at layer 3 and
> at the app layer. The Path MTU refers to the smallest MTU along each
> router hop from the IP source to the IP destination. For SIP, that is
> just a single "hop" from the UAC to a proxy, say. Each SIP "hop"
> (between UAC and proxy, or proxy to proxy) will have a different path
> MTU, and could conceivably make a different transport decision based on
> that.

Ah, thanks for the terminology lession--I mean to say, that it is very
unlikely that the MTU will know the smallest path MTU for every SIP device
end-to-end.



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


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



From daemon@optimus.ietf.org  Fri May 17 13:17:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21820
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 13:17:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA20213
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 13:18:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18620;
	Fri, 17 May 2002 12:47:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18589
	for <sip@optimus.ietf.org>; Fri, 17 May 2002 12:47:35 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20370
	for <sip@ietf.org>; Fri, 17 May 2002 12:47:19 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4HGlXr19335;
	Fri, 17 May 2002 12:47:34 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id LAA02935; Fri, 17 May 2002 11:47:32 -0500 (CDT)
Message-ID: <3CE53421.1050903@lucent.com>
Date: Fri, 17 May 2002 11:47:29 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: SIP LIST <sip@ietf.org>
Subject: Re: [Sip] Repost: Timer C, Timer B and Spiraling
References: <3CE42BED.3070109@lucent.com> <3CE523BE.B75B8BDC@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
[...]
>>Looking at Figure 5, it seems that UAC will also benefit from a
>>dynamic transaction timeout window.  Furthermore, why set Timer B in
>>the "Calling" state?  If UDP is being used, we will know on the second
>>retx that a UAS does not exist (if the socket is bind()'ed to the UAS --
>>funny, this is missing from -09bis).  If TCP (or TLS, or I believe even
>>SCTP) is being used, the connection will fail right away.  So, a
>>transport error is bound to occur in the "Calling" state if a UAS does
>>not exist.  Is it possible to set timer B in the "Proceeding" state and
>>initalize it to the value of the Expires header (if present, T1*64 if
>>not) and then dynamically updated on provisionals, just like proxies?
>  
> I'm lost. Timer B handles time outs because of no response whatsoever.

OK; let me explain...in Figure 5, Calling state is exited when either of
the following events occur:

    (1) Receipt of a 2xx
    (2) Receipt of a 1xx
    (3) Timer B fires
    (4) Transport error

In case of UDP, a transport error will occur when the request is retx'd
on a bound socket where a server is not listening.  In case of TCP
(TLS/TCP) and SCTP, a transport error will occur as soon as an attempt
is made to establish a connection to an address where a server is not
listening.  Control thus always goes to Terminated state in case of a
transport error (event (4)).  Control also goes to Terminated state when
a 2xx is received while in Calling state (event (1)).

So that leaves events (2) and (3) for exiting Calling state.  If we
receive a 1xx (event (2)), we transit to Proceeding state as normal and
*then* start Timer B.

If we do not start Timer B in the Calling state, we are guaranteed to
have exited Calling state either through events (4) (2) or (1).  If we
exit Calling state due to event (2), we can *then* start Timer B.  This
has the nice side-effect of maintaining a dynamic Timer B (mirroring
Timer C for proxies).

BTW, in -09bis I notice that binding UDP sockets to destination
addresses (so that a ECONNREFUSED is generated on a retx) has been
taken out.  Was this intentional or a an error.  What I describe
above depends on a bound UDP socket.

Also note that even if a UAC core does put an "Expires: 60" in a
request, the client transaction will still time out in 32 s (T1*64) as
per -09bis.  Suggested change to the sentence on line 3274 (-09bis,
PDF):
    "For any transport, the client transaction MUST start timer B
     with a value of the Expires header, if present, or 64*T1 if not."

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216


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



From daemon@ns.ietf.org  Fri May 17 15:30:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00323
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 15:30:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA27499
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 15:31:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25862;
	Fri, 17 May 2002 15:01:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25834
	for <sip@ns.ietf.org>; Fri, 17 May 2002 15:01:26 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27825
	for <sip@ietf.org>; Fri, 17 May 2002 15:01:11 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4HJ0Ed11561;
	Fri, 17 May 2002 14:00:14 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "'Sean Olson'" <seancolson@yahoo.com>,
        "'Ben Campbell'" <bcampbell@dynamicsoft.com>, <aki.niemi@nokia.com>,
        <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Fri, 17 May 2002 13:59:40 -0500
Message-ID: <003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <15589.10039.127865.917811@thomasm-u1.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


One must ask -- at what point should one transition from IM to email?

Mike rote:
> Jonathan Rosenberg writes:
>  > 
>  > 
>  > Sean Olson wrote:
>  > > 
>  > > The consent piece is an interesting adjunct to the
>  > > content indirection requirements. I already allude
>  > > to the fact that you need to be able to negotiate
>  > > support / demand for such a mechanism.
>  > > 
>  > > Do we need to express explicit policy about when
>  > > content indirection should be used?
>  > 
>  > What I was saying is that the page mode spec DEFINES that 
> policy  > explicitly - anything over 1300 bytes means indirection.
> 
> 
> Jonathan,
> 
> While I like the spirit of your proposal, I wonder
> if it's going to run into operational problems.
> Client's don't typically run web servers
. . . 
> short term/transient data that seems like a pretty
> big burden.
> 
> When we discussed this ages ago it was in the
> context of inlining jpeg mug shots and the like.
> However if the context is IM, I'm not so sure
> again. 


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



From daemon@ns.ietf.org  Fri May 17 15:42:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01265
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 15:42:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA28365
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 15:42:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26353;
	Fri, 17 May 2002 15:14:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA26319
	for <sip@ns.ietf.org>; Fri, 17 May 2002 15:14:55 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28544
	for <sip@ietf.org>; Fri, 17 May 2002 15:14:40 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4HJE9uF008741;
	Fri, 17 May 2002 12:14:09 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABR54045;
	Fri, 17 May 2002 12:11:14 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA01781; Fri, 17 May 2002 12:14:16 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15589.22152.263398.962375@thomasm-u1.cisco.com>
Date: Fri, 17 May 2002 12:14:16 -0700 (PDT)
To: "Dean Willis" <dean.willis@softarmor.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>,
        "'Ben Campbell'" <bcampbell@dynamicsoft.com>, <aki.niemi@nokia.com>,
        <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
In-Reply-To: <003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2>
References: <15589.10039.127865.917811@thomasm-u1.cisco.com>
	<003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Dean Willis writes:
 > 
 > One must ask -- at what point should one transition from IM to
 > email?

   Immediately?

	Mike, buddyless

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



From daemon@ns.ietf.org  Fri May 17 16:23:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02804
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 16:23:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA29758
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 16:23:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28674;
	Fri, 17 May 2002 15:51:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA28643
	for <sip@ns.ietf.org>; Fri, 17 May 2002 15:51:52 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01686
	for <sip@ietf.org>; Fri, 17 May 2002 15:51:36 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA06492;
	Fri, 17 May 2002 15:51:36 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4HJpZ2i022695
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 17 May 2002 15:51:35 -0400 (EDT)
Message-ID: <3CE55F35.4020107@cs.columbia.edu>
Date: Fri, 17 May 2002 15:51:17 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
CC: Dean Willis <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'"
 <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>,
        "'Ben Campbell'"
 <bcampbell@dynamicsoft.com>, aki.niemi@nokia.com,
        sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
References: <15589.10039.127865.917811@thomasm-u1.cisco.com>	<003a01c1fdd4$fff56190$1d036e3f@TXDWILLIS2> <15589.22152.263398.962375@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Joking aside, this may not be such a bad idea: Send an IM with a message 
reference, with email sent simultaneously. Generally, mail delivery is 
measured in seconds (and for the long messages we're talking about here, 
any processing delays would tend to be overwhelmed by transport delays). 
Avoids all firewall, cable modem restriction and NAT issues and, to 
boot, leverages off the likelihood that SIP and SMTP address are the 
same. Plus, with IMAP, the client already gets to decide whether to 
download attachments or not.

Michael Thomas wrote:
> Dean Willis writes:
>  > 
>  > One must ask -- at what point should one transition from IM to
>  > email?
> 
>    Immediately?


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



From daemon@ns.ietf.org  Fri May 17 17:32:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07107
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 17:32:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA04304
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:32:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02528;
	Fri, 17 May 2002 17:02:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02497
	for <sip@ns.ietf.org>; Fri, 17 May 2002 17:02:53 -0400 (EDT)
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04905
	for <sip@ietf.org>; Fri, 17 May 2002 17:02:37 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4HL2LI32393
	for <sip@ietf.org>; Fri, 17 May 2002 16:02:21 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZSY5Q>; Fri, 17 May 2002 16:02:16 -0500
Message-ID: <70565611B164D511957A001083FCDD560187031C@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Fri, 17 May 2002 16:02:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Asserted-Identity: How to 'hint'?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


In the course of the discussion between Mark Watson, Cullen Jennings and
myself about the short-term identity work, we have returned a few times to
the question of the infamous hint. This hint is, of course, a way that a
user agent (one that is not a member of the Trust Domain in the short-term
network asserted identity space) can provide a 'hint' to the intermediary
that will generate an Asserted-Identity indicating which identity among
several possibilities should be asserted.

The need for this arises particularly from the 3G space, in which the
authentication process takes place independently of SIP and does not carry
this sort of personal identity information. It also assumes that the
operators of the intermediary in question are aware of several legitimate
identities which the user can elect to assert.

It has been proposed on the mailing list and elsewhere that the
Asserted-Identity header should be re-used by user agents outside the Trust
Domain to provide such a hint. I see a number of reasons for and against
using the Asserted-Identity for this purpose. For example, today, there is a
requirement that asserted-identities which are transmitted from untrusted
sources should not be used in any way - this would seem to weaken that
requirement. There is also possibly some behavior that still needs to be
specified (like how an intermediary would reject or otherwise handle a
request with an inappropriate hint) that might be impactful to our choice.

For the time being, however, I would like to suggest that providing the hint
is outside the scope of the current deliverables (the asserted-identity
requirements and mechanism drafts), which need to be complete, as we
discussed in the interim meeting, by the end of this month. I believe that a
separate draft should propose the use of Asserted-Identity or any other
header for this hint (in whatever timeframe is appropriate for 3G's
requirements), but that we should not speak to this matter in the current
asserted-identity deliverables. There is, as I see it, no dependency on
defining this hint before we dictate how intermediaries will assert
identities.

Any comments on this plan?

Jon Peterson
NeuStar, Inc.

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



From daemon@ns.ietf.org  Fri May 17 17:48:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07921
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 17:48:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA04578
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:48:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03225;
	Fri, 17 May 2002 17:17:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03178
	for <sip@ns.ietf.org>; Fri, 17 May 2002 17:17:26 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06047
	for <sip@ietf.org>; Fri, 17 May 2002 17:17:10 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4HLGnX26667;
	Fri, 17 May 2002 16:16:49 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
        "Michael Thomas" <mat@cisco.com>,
        "Dean Willis" <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>, <aki.niemi@nokia.com>
Cc: <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Fri, 17 May 2002 16:16:40 -0500
Message-ID: <HNEOJECGFHIABDLENMMCGEOMCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3CE55F35.4020107@cs.columbia.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

OK, to summarize where I think we are, I have seen 4 proposals for dealing
with the message size controversy:

1) Just live with it. IM's are not designed to carry large content anyway.
Large content should be sent using some other mechanism, like in-session
messages, content indirection, or something completely different like email.
(bottom line: limit stays, with perhaps a clarification of the how the limit
relates to the lowest hop MTU.)

2) Fix the SIP "feature" that creates this problem in the first place, i.e.
the fact that a proxy can fail over to UDP even when a congestion controlled
transport is requested. Jonathan suggested dissallowing this proxy behavior
for large content messages. I'm not sure how hard that charge would be to
get into 3261.

3) Adding something like a proxy-require:contestion-safe tag, so that the
UAC can insist on end-to-end congestion control. This of course means that
large content MESSAGE requests could not pass _any_ existing proxies--but
that is no more limiting than saying you can't have large content messages
at all. It at least gives us a way to relax the limit if we someday do get
proxies that support the tag.

4) Relax the limit back to a should, but take no further action. I do not
think that would pass IESG muster at this point.

Personally I lean towards option 1. Pager model IMs are really _not_
intended to be a file transfer mechanism. Even without a strict limit, I
think that large content messages (where content is physically carried in
the message) are a misuse of the mechanism. We should work to specify an
indirect-content mechanism, a session based mechanism, or both. But those
are out of scope for pager model messaging, and should not become a
dependency for this draft. Option 4 is pretty much out of the question. 2 &
3 may be doable, but are significant enough that we might need to re-cycle
the last call.

This really seems to be a full circle discussion, back to IMPP requirements
days. I think our best bet is to narrow the scope to something
solveable--that is short text (or otherwise small content) instant messages,
solve that, then work on more sophisticated mechanisms for large content.

Thoughts?

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, May 17, 2002 2:51 PM
> To: Michael Thomas
> Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell';
> aki.niemi@nokia.com; sip@ietf.org
> Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
>
>
> Joking aside, this may not be such a bad idea: Send an IM with a message
> reference, with email sent simultaneously. Generally, mail delivery is
> measured in seconds (and for the long messages we're talking about here,
> any processing delays would tend to be overwhelmed by transport delays).
> Avoids all firewall, cable modem restriction and NAT issues and, to
> boot, leverages off the likelihood that SIP and SMTP address are the
> same. Plus, with IMAP, the client already gets to decide whether to
> download attachments or not.
>
> Michael Thomas wrote:
> > Dean Willis writes:
> >  >
> >  > One must ask -- at what point should one transition from IM to
> >  > email?
> >
> >    Immediately?


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



From daemon@ns.ietf.org  Fri May 17 17:50:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08101
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 17:50:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA04609
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:50:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03724;
	Fri, 17 May 2002 17:29:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03694
	for <sip@ns.ietf.org>; Fri, 17 May 2002 17:28:58 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06761
	for <sip@ietf.org>; Fri, 17 May 2002 17:28:42 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA14023;
	Fri, 17 May 2002 17:28:46 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4HLSi2i027240
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Fri, 17 May 2002 17:28:45 -0400 (EDT)
Message-ID: <3CE575FA.7070800@cs.columbia.edu>
Date: Fri, 17 May 2002 17:28:26 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: Michael Thomas <mat@cisco.com>, Dean Willis
 <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'"
 <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>, aki.niemi@nokia.com,
        sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
References: <HNEOJECGFHIABDLENMMCGEOMCIAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Plus, even if we do (1), this does not preclude (3) and maybe even (2) 
in the future, should there be a demonstrated need.

Ben Campbell wrote:
> OK, to summarize where I think we are, I have seen 4 proposals for dealing
> with the message size controversy:
> 
> 1) Just live with it. IM's are not designed to carry large content anyway.
> Large content should be sent using some other mechanism, like in-session
> messages, content indirection, or something completely different like email.
> (bottom line: limit stays, with perhaps a clarification of the how the limit
> relates to the lowest hop MTU.)
> 
> 2) Fix the SIP "feature" that creates this problem in the first place, i.e.
> the fact that a proxy can fail over to UDP even when a congestion controlled
> transport is requested. Jonathan suggested dissallowing this proxy behavior
> for large content messages. I'm not sure how hard that charge would be to
> get into 3261.
> 
> 3) Adding something like a proxy-require:contestion-safe tag, so that the
> UAC can insist on end-to-end congestion control. This of course means that
> large content MESSAGE requests could not pass _any_ existing proxies--but
> that is no more limiting than saying you can't have large content messages
> at all. It at least gives us a way to relax the limit if we someday do get
> proxies that support the tag.
> 
> 4) Relax the limit back to a should, but take no further action. I do not
> think that would pass IESG muster at this point.
> 
> Personally I lean towards option 1. Pager model IMs are really _not_
> intended to be a file transfer mechanism. Even without a strict limit, I
> think that large content messages (where content is physically carried in
> the message) are a misuse of the mechanism. We should work to specify an
> indirect-content mechanism, a session based mechanism, or both. But those
> are out of scope for pager model messaging, and should not become a
> dependency for this draft. Option 4 is pretty much out of the question. 2 &
> 3 may be doable, but are significant enough that we might need to re-cycle
> the last call.
> 
> This really seems to be a full circle discussion, back to IMPP requirements
> days. I think our best bet is to narrow the scope to something
> solveable--that is short text (or otherwise small content) instant messages,
> solve that, then work on more sophisticated mechanisms for large content.
> 
> Thoughts?
> 
> 
>>-----Original Message-----
>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
>>Sent: Friday, May 17, 2002 2:51 PM
>>To: Michael Thomas
>>Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell';
>>aki.niemi@nokia.com; sip@ietf.org
>>Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
>>changes)
>>
>>
>>Joking aside, this may not be such a bad idea: Send an IM with a message
>>reference, with email sent simultaneously. Generally, mail delivery is
>>measured in seconds (and for the long messages we're talking about here,
>>any processing delays would tend to be overwhelmed by transport delays).
>>Avoids all firewall, cable modem restriction and NAT issues and, to
>>boot, leverages off the likelihood that SIP and SMTP address are the
>>same. Plus, with IMAP, the client already gets to decide whether to
>>download attachments or not.
>>
>>Michael Thomas wrote:
>>
>>>Dean Willis writes:
>>> >
>>> > One must ask -- at what point should one transition from IM to
>>> > email?
>>>
>>>   Immediately?
>>



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



From daemon@ns.ietf.org  Fri May 17 17:53:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08249
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 17:53:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA04706
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 17:53:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03187;
	Fri, 17 May 2002 17:17:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA03110
	for <sip@ns.ietf.org>; Fri, 17 May 2002 17:17:23 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06040;
	Fri, 17 May 2002 17:17:04 -0400 (EDT)
Message-Id: <200205172117.RAA06040@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>,
        sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Date: Fri, 17 May 2002 17:17:04 -0400
Subject: [Sip] Protocol Action: The Session Initiation Protocol UPDATE Method
 to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org



The IESG has approved the publication of the following two I-Ds as
Proposed Standards:

 o The Session Initiation Protocol UPDATE Method
	<draft-ietf-sip-update-02.txt>

 o Integration of Resource Management and SIP 
	<draft-ietf-sip-manyfolks-resource-07.txt> 

These documents are the product of the Session Initiation Protocol
Working Group.  The IESG contact persons are Allison Mankin and Scott
Bradner.

 
Technical Summary
 
      UPDATE is a new method for the Session Initiation protocol.  It
      allows a client to update parameters of a session (such as the
      set of media streams and their codecs) but has no impact on the
      state of the dialog. This means that it functions like a
      re-INVITE (sending a second INVITE methd), but it can be sent
      before the initial INVITE has completed, and therefore can serve
      purposes of early dialog negotiation. UPDATE needs source
      authentication and integrity protection, which are provided by
      mechanisms in RFC BBBB, the SIP protocol specification.

      Some architectures require that at session establishment time,
      once the callee has been alerted, the chances of a session
      establishment failure are minimum. One source of failure is the
      inability to reserve network resources for a session. In order to
      minimize "ghost rings", it is necessary to reserve network
      resources for the session before the callee is alerted. However,
      the reservation of network resources frequently requires learning
      the IP address, port, and session parameters from the callee.
      This information is obtained as a result of the initial offer/
      answer Exchange carried in SIP. This exchange normally causes the
      "phone To ring", thus introducing a chicken-and-egg problem:
      resources cannot be reserved without performing an initial
      offer/answer exchange, and the initial offer/answer exchange
      can't be done without performing resource reservation.

      The solution is to introduce the concept of a precondition.  A
      precondition is a set of constraints about the session which are
      introduced in the offer. The recipient of the offer generates an
      answer, but does not alert the user or otherwise proceed with
      session establishment. That only occurs when the preconditions
      are met. This can be known through a local event (such as a
      confirmation of a resource reservation), or through a new offer
      sent by the caller. Any specifics of resource reservation
      mechanisms or how a SIP endpoint might get local confirmation of
      the precondition being met are outside the scope of resource
      management integration specification.

      The preconditions are defined in the Session Description Protocol
      (SDP) parameters for the session, and the exchange in the SDP
      offer-answer, because they apply to specific media streams
      identified with the SDP body in SIP. Security needed for the
      preconditions exchanges includes source authentication and
      integrity protection, and these are provided by mechanisms in RFC
      BBBB.

Working Group Summary
 
      The resource management integration spec was simplified
      considerably by the introduction of the UPDATE method.
      After that simplifying revision, both specs were strongly
      supported by the working group for advancement.
 
Protocol Quality
 
      The specifications were reviewed for the IESG by Allison Mankin.
      John Loughney also did a careful review of the resource
      management integration spec.

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



From daemon@ns.ietf.org  Fri May 17 18:02:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08643
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 18:02:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA05344
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:02:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04450;
	Fri, 17 May 2002 17:40:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04419
	for <sip@ns.ietf.org>; Fri, 17 May 2002 17:40:05 -0400 (EDT)
Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07423
	for <sip@ietf.org>; Fri, 17 May 2002 17:39:49 -0400 (EDT)
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g4HLe3B08914;
	Fri, 17 May 2002 17:40:03 -0400 (EDT)
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "Ben Campbell" <bcampbell@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Fri, 17 May 2002 17:41:21 -0400
Message-ID: <BEEMKJGAMKLMAIKEECBAEELPCEAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <HNEOJECGFHIABDLENMMCGEOMCIAA.bcampbell@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

If we can wait, I would actually rather do #3.

#2 is a non-starter; there are too many proxies that would blithely pass
along the content.

#4 is a non-starter; this is asking to break the Internet.  We all know that
people will use IM instead of e-mail to send that 4MB presentation and that
3GB movie.

#1, which works, is a hack.  It also will break some QoS schemes.  E.g., SIP
signaling gets higher priority than e-mail.

#3 is, in a sense the correct answer (short of the truly correct answer on
not sending content in a session initiation protocol, but that's another
flame...).  If the question of the proxy is, "can you safely transmit
this?", then let us ask that question!

To show the silliness of sending content in a session protocol, another
solution that has not been mentioned yet would be to put congestion control
into SIP #-)))   [eyes shut closed!]

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Ben
Campbell
Sent: Friday, May 17, 2002 5:17 PM
To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan
Rosenberg'; 'Sean Olson'; aki.niemi@nokia.com
Cc: sip@ietf.org
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
changes)


OK, to summarize where I think we are, I have seen 4 proposals for dealing
with the message size controversy:

1) Just live with it. IM's are not designed to carry large content anyway.
Large content should be sent using some other mechanism, like in-session
messages, content indirection, or something completely different like email.
(bottom line: limit stays, with perhaps a clarification of the how the limit
relates to the lowest hop MTU.)

2) Fix the SIP "feature" that creates this problem in the first place, i.e.
the fact that a proxy can fail over to UDP even when a congestion controlled
transport is requested. Jonathan suggested dissallowing this proxy behavior
for large content messages. I'm not sure how hard that charge would be to
get into 3261.

3) Adding something like a proxy-require:contestion-safe tag, so that the
UAC can insist on end-to-end congestion control. This of course means that
large content MESSAGE requests could not pass _any_ existing proxies--but
that is no more limiting than saying you can't have large content messages
at all. It at least gives us a way to relax the limit if we someday do get
proxies that support the tag.

4) Relax the limit back to a should, but take no further action. I do not
think that would pass IESG muster at this point.

Personally I lean towards option 1. Pager model IMs are really _not_
intended to be a file transfer mechanism. Even without a strict limit, I
think that large content messages (where content is physically carried in
the message) are a misuse of the mechanism. We should work to specify an
indirect-content mechanism, a session based mechanism, or both. But those
are out of scope for pager model messaging, and should not become a
dependency for this draft. Option 4 is pretty much out of the question. 2 &
3 may be doable, but are significant enough that we might need to re-cycle
the last call.

This really seems to be a full circle discussion, back to IMPP requirements
days. I think our best bet is to narrow the scope to something
solveable--that is short text (or otherwise small content) instant messages,
solve that, then work on more sophisticated mechanisms for large content.

Thoughts?


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



From daemon@ns.ietf.org  Fri May 17 18:14:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09083
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 18:14:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA05646
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:14:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04668;
	Fri, 17 May 2002 17:52:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04637
	for <sip@ns.ietf.org>; Fri, 17 May 2002 17:52:39 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08196
	for <sip@ietf.org>; Fri, 17 May 2002 17:52:23 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4HLq7X29043;
	Fri, 17 May 2002 16:52:07 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Michael Thomas" <mat@cisco.com>,
        "Dean Willis" <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>, <aki.niemi@nokia.com>,
        <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Fri, 17 May 2002 16:51:58 -0500
Message-ID: <HNEOJECGFHIABDLENMMCMEOOCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CE575FA.7070800@cs.columbia.edu>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Agreed, although the current wording might preclude that. Maybe it would be
worth a slight mod that says if you _know_ all hops are congestion
controlled, you can exceed the limit. Then a future solution for 2 and 3
would not be precluded.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Friday, May 17, 2002 4:28 PM
> To: Ben Campbell
> Cc: Michael Thomas; Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson';
> aki.niemi@nokia.com; sip@ietf.org
> Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
>
>
> Plus, even if we do (1), this does not preclude (3) and maybe even (2)
> in the future, should there be a demonstrated need.
>
> Ben Campbell wrote:
> > OK, to summarize where I think we are, I have seen 4 proposals
> for dealing
> > with the message size controversy:
> >
> > 1) Just live with it. IM's are not designed to carry large
> content anyway.
> > Large content should be sent using some other mechanism, like in-session
> > messages, content indirection, or something completely
> different like email.
> > (bottom line: limit stays, with perhaps a clarification of the
> how the limit
> > relates to the lowest hop MTU.)
> >
> > 2) Fix the SIP "feature" that creates this problem in the first
> place, i.e.
> > the fact that a proxy can fail over to UDP even when a
> congestion controlled
> > transport is requested. Jonathan suggested dissallowing this
> proxy behavior
> > for large content messages. I'm not sure how hard that charge
> would be to
> > get into 3261.
> >
> > 3) Adding something like a proxy-require:contestion-safe tag,
> so that the
> > UAC can insist on end-to-end congestion control. This of course
> means that
> > large content MESSAGE requests could not pass _any_ existing
> proxies--but
> > that is no more limiting than saying you can't have large
> content messages
> > at all. It at least gives us a way to relax the limit if we
> someday do get
> > proxies that support the tag.
> >
> > 4) Relax the limit back to a should, but take no further
> action. I do not
> > think that would pass IESG muster at this point.
> >
> > Personally I lean towards option 1. Pager model IMs are really _not_
> > intended to be a file transfer mechanism. Even without a strict limit, I
> > think that large content messages (where content is physically
> carried in
> > the message) are a misuse of the mechanism. We should work to specify an
> > indirect-content mechanism, a session based mechanism, or both.
> But those
> > are out of scope for pager model messaging, and should not become a
> > dependency for this draft. Option 4 is pretty much out of the
> question. 2 &
> > 3 may be doable, but are significant enough that we might need
> to re-cycle
> > the last call.
> >
> > This really seems to be a full circle discussion, back to IMPP
> requirements
> > days. I think our best bet is to narrow the scope to something
> > solveable--that is short text (or otherwise small content)
> instant messages,
> > solve that, then work on more sophisticated mechanisms for
> large content.
> >
> > Thoughts?
> >
> >
> >>-----Original Message-----
> >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> >>Sent: Friday, May 17, 2002 2:51 PM
> >>To: Michael Thomas
> >>Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell';
> >>aki.niemi@nokia.com; sip@ietf.org
> >>Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
> >>changes)
> >>
> >>
> >>Joking aside, this may not be such a bad idea: Send an IM with a message
> >>reference, with email sent simultaneously. Generally, mail delivery is
> >>measured in seconds (and for the long messages we're talking about here,
> >>any processing delays would tend to be overwhelmed by transport delays).
> >>Avoids all firewall, cable modem restriction and NAT issues and, to
> >>boot, leverages off the likelihood that SIP and SMTP address are the
> >>same. Plus, with IMAP, the client already gets to decide whether to
> >>download attachments or not.
> >>
> >>Michael Thomas wrote:
> >>
> >>>Dean Willis writes:
> >>> >
> >>> > One must ask -- at what point should one transition from IM to
> >>> > email?
> >>>
> >>>   Immediately?
> >>
>


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



From daemon@ns.ietf.org  Fri May 17 18:25:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09507
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 18:25:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA05905
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:25:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05397;
	Fri, 17 May 2002 18:04:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA05370
	for <sip@ns.ietf.org>; Fri, 17 May 2002 18:04:23 -0400 (EDT)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08720
	for <sip@ietf.org>; Fri, 17 May 2002 18:04:04 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4HM3dc21042
	for <sip@ietf.org>; Fri, 17 May 2002 18:03:39 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZSZK8>; Fri, 17 May 2002 17:03:34 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870320@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Fri, 17 May 2002 17:03:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Asserted-Identity: A P- Header?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


There has been some substantial discussion in this working group about the
naming of the new header for the short-term network asserted identity work.
Although it took us some time to arrive on an agreeable name, I'd like to
suggest a slight modification to 'Asserted-Identity' - namely that it become
a P- header.

P- headers are defined in the 'sipchange' draft that discusses how
extensions to SIP should be created. The P- is short for 'preliminary',
'private', or 'proprietary' - and in fact, I think the Asserted-Identity
header for the short-term work is in fact compatible with all three of those
adjectives. More substantially, there are also specific criteria for P-
headers provided in the sipchange draft (in section 6.1) and I believe
Asserted-Identity is a good match for nearly all of those criteria.

sipchange says that P- headers may be appropriate when extensions "are
private or proprietary in nature, because a characteristic motivating them
is usage that is known not to fit the Internet architecture for SIP." As an
extension, short-term asserted identity does not define new methods,
responses codes, or option tags (criterion 2). The header is purely
informational in nature (criterion 4). Asserted-Identity also bears a
significant applicability statement (criterion 7). The current draft also
meets the constraints identified by criteria 2 and 3. I'm sure we could get
Expert Review as specified in criterion 1, and that the document could be
passed as described by criterion 6. 

What do we gain by making Asserted-Identity a P- header? Really only
political leeway; this doesn't entail any changes to how the header works.
But the underlying Trust Domain model of the short-term identity work is not
very compatible with the Internet model, and this may very well cause us
some consternation moving forward this document (some discomfiture along
these lines was previously expressed over sip-privacy-04). By making this
header a P- header we can deflect this sort of criticism by identifying this
as work that is known to be specific to private networks that do not adhere
to the Internet model as such. sipchange introduced this concept
specifically so that we could get this sort of header passed. If we aren't
using the P- header for this, I'm not sure what we'd use it for.

One thing that I know we lose by making Asserted-Identity a P- header is
that the long-term identity story would no longer use the same header name
as the short-term identity work. However, since the interface between
long-term, certificate-based identity and short-term, trust-based identity
will be defined as a gatewaying process, we really don't incur any cost from
using different headers. Personally, I still feel there is something to be
gained by using 'From' as the header in the long-term story (specifically,
this jibes in certain ways with existing S/MIME behavior in rfc3261). So I
suppose I don't find this loss to be troubling.

Thoughts?

Jon Peterson
NeuStar, Inc.

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



From daemon@ns.ietf.org  Fri May 17 18:56:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11110
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 18:56:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA08766
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:56:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07428;
	Fri, 17 May 2002 18:36:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07379
	for <sip@ns.ietf.org>; Fri, 17 May 2002 18:36:17 -0400 (EDT)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10172
	for <sip@ietf.org>; Fri, 17 May 2002 18:36:01 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4HMZfc21495;
	Fri, 17 May 2002 18:35:41 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZSZSV>; Fri, 17 May 2002 17:35:36 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870322@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Natasha Varshney'" <natasha_varshney@yahoo.com>, sip@ietf.org
Subject: RE: [Sip] (no subject)
Date: Fri, 17 May 2002 17:35:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FDF3.266BBE00"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C1FDF3.266BBE00
Content-Type: text/plain;
	charset="iso-8859-1"

Unfortunately, we only have 'working papers' at the moment, and these are as
technical as papers on this subject are likely to get. Be sure to look at
rfc2543bis-09, especially sections 22, 23 and 26 on security, since this
material is more or less final now. There are a number of drafts examining
the general privacy and identity concepts in SIP at the moment; it is a bit
of a hot topic. However, the privacy story at least should be stable by the
end of this month.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Natasha Varshney [mailto:natasha_varshney@yahoo.com]
Sent: Thursday, May 16, 2002 5:37 PM
To: sip@ietf.org
Subject: [Sip] (no subject)



Hi All,

I am doing a research project on SIP security  and privacy
considerations.All I  found was the working papers on the subject.Iam
looking for some technical papers if available.If anyone can help...

Thanks




  _____  

Do You Yahoo!?
LAUNCH <http://rd.yahoo.com/welcome/*http://launch.yahoo.com>  - Your Yahoo!
Music Experience


------_=_NextPart_001_01C1FDF3.266BBE00
Content-Type: text/html;
	charset="iso-8859-1"

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


<META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=058383322-17052002>Unfortunately, we only have 'working papers' at the 
moment, and these are as technical as papers on this subject are likely to get. 
Be sure to look at rfc2543bis-09, especially sections 22, 23 and 26 on security, 
since this material is more or less final now. There are a number of drafts 
examining the general privacy and identity concepts in SIP at the moment; it is 
a bit of a hot topic. However, the privacy story at least should be stable by 
the end of this month.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=058383322-17052002>Jon 
Peterson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=058383322-17052002>NeuStar, Inc.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Natasha Varshney 
  [mailto:natasha_varshney@yahoo.com]<BR><B>Sent:</B> Thursday, May 16, 2002 
  5:37 PM<BR><B>To:</B> sip@ietf.org<BR><B>Subject:</B> [Sip] (no 
  subject)<BR><BR></DIV></FONT>
  <P>Hi All,</P>
  <P>I am doing a research project on SIP security&nbsp; and privacy 
  considerations.All&nbsp;I &nbsp;found was the working papers on the 
  subject.Iam looking for some technical papers if available.If anyone can 
  help...</P>
  <P>Thanks</P>
  <P><BR>
  <HR SIZE=1>
  <B>Do You Yahoo!?</B><BR><A 
  href="http://rd.yahoo.com/welcome/*http://launch.yahoo.com">LAUNCH</A> - Your 
  Yahoo! Music Experience</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1FDF3.266BBE00--

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



From daemon@ns.ietf.org  Fri May 17 18:57:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11171
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 18:57:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA08847
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 18:57:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07770;
	Fri, 17 May 2002 18:39:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07736
	for <sip@ns.ietf.org>; Fri, 17 May 2002 18:39:10 -0400 (EDT)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10309
	for <sip@ietf.org>; Fri, 17 May 2002 18:38:53 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4HMc1c21520;
	Fri, 17 May 2002 18:38:02 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZSZS9>; Fri, 17 May 2002 17:37:56 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870323@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>
Cc: "'Robert Sparks'" <rsparks@dynamicsoft.com>, sip@ietf.org
Subject: RE: [Sip] RE: Comment on sip-identity-00
Date: Fri, 17 May 2002 17:37:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


Currently, my identity draft allows an authentication service to sign a
header that represents a SIP[S] URI, some other headers that provide
reference integrity, and optionally any other headers it would like. Thus if
your network requires a Network Access Identity, as you suggest, that is
distinct from the SIP[S] URI by which a user is identified, that Network
Access Identity could be included in a separate header. So I'd like to think
that the long-term identity story can accomodate your needs. I will be
clarifying the document a bit in this regard as well.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: Monday, May 13, 2002 9:35 PM
> To: Peterson, Jon
> Cc: 'Robert Sparks'; sip@ietf.org
> Subject: [Sip] RE: Comment on sip-identity-00
> 
> 
> Peterson, Jon writes:
> 
>  > These are good points; throughout the identity draft, I 
> tried to use Digest
>  > only as an example, and indeed in plenty of authentication 
> systems the
>  > identifier of a user would not be suitable syntactically 
> or semantically for
>  > the username portion of a SIP URI. I do think it is not 
> unreasonable,
>  > however, in systems like Digest for a user to have an 
> expectation that the
>  > username they enter into an authentication dialog (for 
> example) will be the
>  > username that appears in their authenticated identity.
> 
> i tried to make this same point.  in our case the username used in
> digest authentication is the general NAI (Network Access Identifier) of
> the user and the sip network asserted identity i-d cannot that the
> username used in the digest authentication (or any other authentication
> scheme) has nothing to do with the sip uris the user may have.  the i-d
> should make this requirement explicitly clear and also clearly explain
> that what is asserted is the sip uri the user wants to use for this
> 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
> 

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



From daemon@ns.ietf.org  Fri May 17 19:03:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11367
	for <sip-archive@odin.ietf.org>; Fri, 17 May 2002 19:03:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA09417
	for sip-archive@odin.ietf.org; Fri, 17 May 2002 19:03:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08348;
	Fri, 17 May 2002 18:45:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08320
	for <sip@ns.ietf.org>; Fri, 17 May 2002 18:44:59 -0400 (EDT)
Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10566
	for <sip@ietf.org>; Fri, 17 May 2002 18:44:39 -0400 (EDT)
Received: from victorpc ([206.184.140.167])
	by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g4HMikf32190;
	Fri, 17 May 2002 18:44:46 -0400
From: "Victor Paulsamy" <victor@zapex.com>
To: <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Date: Fri, 17 May 2002 15:43:16 -0700
Message-ID: <NEBBIPNANPGLCDPGFJGPCEJJCEAA.victor@zapex.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Was the Translate heade used?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last but
one reads, "... From this 200 OK, the STUN agent knows whether or not the
Translate header was used or not."

In the example shown, the STUN agent learnt the public IP by querying STUN
sever and changed the outgoing REGISTER appropriately to reflect this. When
this request reaches the proxy, it checks the sent-by value against the
received address; they are same in this case (hence no received= param).
Say, the proxy supports SIP extensions for NAT. The proxy then rewrites the
Translate header with sent-by value (in this case) which is same as the
original value it carried in it. When returned in the 200 OK response, the
STUN agent sees that, the Translate header has the same value that it put
in, yet, the proxy supports the extension for NAT.

So, the Translate header will be different in the response only when the
client does not rewrite the private IPs with public ones in the request.
Will it not be wrong, per the quoted string, to think that the proxy didn't
use the Translate header?

Regards,

--victor

Victor Paulsamy               E-mail: victor@zapex.com
Senior Software Engineer      Phone : 650.930.1339 (Direct)
Zapex Technologies, Inc.      Phone : 650.930.1300 (Main)
Mountain View, CA 94043       Fax   : 650.930.1399


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



From daemon@ns.ietf.org  Sat May 18 01:13:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24924
	for <sip-archive@odin.ietf.org>; Sat, 18 May 2002 01:13:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA29710
	for sip-archive@odin.ietf.org; Sat, 18 May 2002 01:13:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20493;
	Sat, 18 May 2002 00:47:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20462
	for <sip@ns.ietf.org>; Sat, 18 May 2002 00:47:27 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24029
	for <sip@ietf.org>; Sat, 18 May 2002 00:47:08 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 178w7m-0003GK-00; Sat, 18 May 2002 07:47:22 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15589.56538.116801.546774@harjus.eng.song.fi>
Date: Sat, 18 May 2002 07:47:22 +0300
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: [Sip] Asserted-Identity: How to 'hint'?
In-Reply-To: <70565611B164D511957A001083FCDD560187031C@va02.va.neustar.com>
References: <70565611B164D511957A001083FCDD560187031C@va02.va.neustar.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Peterson, Jon writes:

 > For the time being, however, I would like to suggest that providing the hint
 > is outside the scope of the current deliverables (the asserted-identity
 > requirements and mechanism drafts), which need to be complete, as we
 > discussed in the interim meeting, by the end of this month. I believe that a
 > separate draft should propose the use of Asserted-Identity or any other
 > header for this hint (in whatever timeframe is appropriate for 3G's
 > requirements), but that we should not speak to this matter in the current
 > asserted-identity deliverables. There is, as I see it, no dependency on
 > defining this hint before we dictate how intermediaries will assert
 > identities.
 > 
 > Any comments on this plan?

first, i don't like at all the idea that ietf sip working group
discussions are dictated and constrained by 3gpp schedules.  we must
have time to really solve the problems and not just hide them under the
carpet because of 3gpp.

second, it is not possible to assert a sip identity of a user without
the hint capability in case the user has more than one possible sip
identity, because in that case the asserting entity would have no other
choice than to reject the call.

third, i don't see the hinting problem to be so complex that it would
need to be hidden under the carper.  in case the caller doesn't want to
be anonymous, the sip uri in the from header can serve as the hint.
this is also good because of backwards compatibility.  in case the from
header is "Anonymous", the hint needs to be provided by another header
that looks like the from header.  we could call it anything, for
example, Really-From.

-- 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 daemon@ns.ietf.org  Sat May 18 01:18:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25082
	for <sip-archive@odin.ietf.org>; Sat, 18 May 2002 01:18:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA29765
	for sip-archive@odin.ietf.org; Sat, 18 May 2002 01:18:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21090;
	Sat, 18 May 2002 00:54:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21059
	for <sip@ns.ietf.org>; Sat, 18 May 2002 00:54:22 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24252
	for <sip@ietf.org>; Sat, 18 May 2002 00:54:07 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 178wEW-0003GT-00; Sat, 18 May 2002 07:54:20 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15589.56956.537034.331285@harjus.eng.song.fi>
Date: Sat, 18 May 2002 07:54:20 +0300
To: "Ben Campbell" <bcampbell@dynamicsoft.com>
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
        "Michael Thomas" <mat@cisco.com>,
        "Dean Willis" <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>, <aki.niemi@nokia.com>,
        <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
In-Reply-To: <HNEOJECGFHIABDLENMMCGEOMCIAA.bcampbell@dynamicsoft.com>
References: <3CE55F35.4020107@cs.columbia.edu>
	<HNEOJECGFHIABDLENMMCGEOMCIAA.bcampbell@dynamicsoft.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Ben Campbell writes:

 > 2) Fix the SIP "feature" that creates this problem in the first place, i.e.
 > the fact that a proxy can fail over to UDP even when a congestion controlled
 > transport is requested. Jonathan suggested dissallowing this proxy behavior
 > for large content messages. I'm not sure how hard that charge would be to
 > get into 3261.

i'm not quite sure what the above means, but i'm in favor of using
hop-by-hop tcp for large messages.  if the next sip hop doesn't speak
tcp, then the message would simply be rejected until the proxy or the us
of the next hop is upgraded.  this is not different from other sip
messages, such as invite, which too can easily be bigger than the mtu of
a link.

-- 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 daemon@optimus.ietf.org  Sat May 18 06:28:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07680
	for <sip-archive@odin.ietf.org>; Sat, 18 May 2002 06:28:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA09355
	for sip-archive@odin.ietf.org; Sat, 18 May 2002 06:29:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08904;
	Sat, 18 May 2002 06:04:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08857
	for <sip@optimus.ietf.org>; Sat, 18 May 2002 06:04:01 -0400 (EDT)
Received: from webmail17.rediffmail.com (webmail17.rediffmail.com [203.199.83.27] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07211
	for <sip@ietf.org>; Sat, 18 May 2002 06:03:43 -0400 (EDT)
Received: (qmail 13738 invoked by uid 510); 18 May 2002 10:03:20 -0000
Date: 18 May 2002 10:03:20 -0000
Message-ID: <20020518100320.13737.qmail@webmail17.rediffmail.com>
Received: from unknown (203.197.251.7) by rediffmail.com via HTTP; 18 May 2002 10:03:20 -0000
MIME-Version: 1.0
From: "Ashhar Farhan" <afarhan@rediffmail.com>
Reply-To: "Ashhar Farhan" <afarhan@rediffmail.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Michael Thomas" <mat@cisco.com>,
        "Dean Willis" <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>, aki.niemi@nokia.com,
        sip@ietf.org, "Ben Campbell" <bcampbell@dynamicsoft.com>
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org



On Sat, 18 May 2002 Henning Schulzrinne wrote :
>Plus, even if we do (1), this does not preclude (3) and maybe 
>even (2) in the future, should there be a demonstrated need.
>

if you have been following the noises from GSM world, multimedia 
messaging is turing out to be a big opportunity (personally, i 
dont agree), but if you consider that MESSAGE may, at a future 
date, also contain very large content, then is it not possible 
that the actual content be a hyperlink in the MESSAGE body?

there are some real problems with using MESSAGE for anything but 
short text messages:

1) it is the charter of SIP that it will use other standardised 
protocols where required rather than provide an alternative. If we 
already have ftp, http and a few more available, then why invent 
yet another one?

2)MESSAGE's main feature is that it is session less so it provides 
a rapid means of messagine without creating any session. this is 
not going to be of any particular advantage when u are going to 
transfer more than a few kilbytes in anycase. In such cases, you 
are better off with other protocols. using MESSAGE as a carrier of 
the URL.

- farhan


_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or 
Abroad
http://monsterindia.rediff.com/jobs


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



From daemon@optimus.ietf.org  Sat May 18 11:14:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16913
	for <sip-archive@odin.ietf.org>; Sat, 18 May 2002 11:14:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA17164
	for sip-archive@odin.ietf.org; Sat, 18 May 2002 11:14:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16441;
	Sat, 18 May 2002 10:54:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16410
	for <sip@optimus.ietf.org>; Sat, 18 May 2002 10:54:14 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16227
	for <sip@ietf.org>; Sat, 18 May 2002 10:53:57 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4IErnX96892;
	Sat, 18 May 2002 09:53:50 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Ashhar Farhan" <afarhan@rediffmail.com>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Michael Thomas" <mat@cisco.com>,
        "Dean Willis" <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <seancolson@yahoo.com>, <aki.niemi@nokia.com>,
        <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Sat, 18 May 2002 09:53:40 -0500
Message-ID: <HNEOJECGFHIABDLENMMCGEPCCIAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <20020518100320.13737.qmail@webmail17.rediffmail.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Farhan,

What you describe is exactly what we mean by content-indirection. The actual
payload is merely a URL that refers to external content. This is a lot like
the external body part feature already available in MIME. We have work in
progress to refine that idea.

>From the rest of your email, I assume you concur with my option 1?

Thanks!

Ben.

> -----Original Message-----
> From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> Sent: Saturday, May 18, 2002 5:03 AM
> To: Henning Schulzrinne
> Cc: Michael Thomas; Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson';
> aki.niemi@nokia.com; sip@ietf.org; Ben Campbell
> Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
>
>
>
>
> On Sat, 18 May 2002 Henning Schulzrinne wrote :
> >Plus, even if we do (1), this does not preclude (3) and maybe
> >even (2) in the future, should there be a demonstrated need.
> >
>
> if you have been following the noises from GSM world, multimedia
> messaging is turing out to be a big opportunity (personally, i
> dont agree), but if you consider that MESSAGE may, at a future
> date, also contain very large content, then is it not possible
> that the actual content be a hyperlink in the MESSAGE body?
>
> there are some real problems with using MESSAGE for anything but
> short text messages:
>
> 1) it is the charter of SIP that it will use other standardised
> protocols where required rather than provide an alternative. If we
> already have ftp, http and a few more available, then why invent
> yet another one?
>
> 2)MESSAGE's main feature is that it is session less so it provides
> a rapid means of messagine without creating any session. this is
> not going to be of any particular advantage when u are going to
> transfer more than a few kilbytes in anycase. In such cases, you
> are better off with other protocols. using MESSAGE as a carrier of
> the URL.
>
> - farhan
>
>
> _________________________________________________________
> Click below to visit monsterindia.com and review jobs in India or
> Abroad
> http://monsterindia.rediff.com/jobs


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



From daemon@optimus.ietf.org  Sat May 18 16:27:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27595
	for <sip-archive@odin.ietf.org>; Sat, 18 May 2002 16:27:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA26577
	for sip-archive@odin.ietf.org; Sat, 18 May 2002 16:27:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26340;
	Sat, 18 May 2002 16:04:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26309
	for <sip@optimus.ietf.org>; Sat, 18 May 2002 16:04:52 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26874
	for <sip@ietf.org>; Sat, 18 May 2002 16:04:36 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4IK5nYH014022;
	Sat, 18 May 2002 16:05:50 -0400 (EDT)
Message-ID: <3CE6B3C1.91A3507@dynamicsoft.com>
Date: Sat, 18 May 2002 16:04:17 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Victor Paulsamy <victor@zapex.com>
CC: sip@ietf.org
References: <NEBBIPNANPGLCDPGFJGPCEJJCEAA.victor@zapex.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Was the Translate heade used?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Victor Paulsamy wrote:
> 
> In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last
> but
> one reads, "... From this 200 OK, the STUN agent knows whether or not
> the
> Translate header was used or not."
> 
> In the example shown, the STUN agent learnt the public IP by querying
> STUN
> sever and changed the outgoing REGISTER appropriately to reflect this.
> When
> this request reaches the proxy, it checks the sent-by value against the
> received address; they are same in this case (hence no received= param).

No, they wouldn't be the same. The registration is sent over TCP, and
uses a different port than was used to communicate with the STUN server. 

> Say, the proxy supports SIP extensions for NAT. The proxy then rewrites
> the
> Translate header with sent-by value (in this case) which is same as the
> original value it carried in it. When returned in the 200 OK response,
> the
> STUN agent sees that, the Translate header has the same value that it
> put
> in, yet, the proxy supports the extension for NAT.

Since the source port is different than the Contact port, the contact
would be rewritten and the client would know.

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Sat May 18 18:14:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01362
	for <sip-archive@odin.ietf.org>; Sat, 18 May 2002 18:14:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA00184
	for sip-archive@odin.ietf.org; Sat, 18 May 2002 18:14:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29397;
	Sat, 18 May 2002 17:48:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA29367
	for <sip@optimus.ietf.org>; Sat, 18 May 2002 17:48:38 -0400 (EDT)
Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00507
	for <sip@ietf.org>; Sat, 18 May 2002 17:48:20 -0400 (EDT)
Received: from ierw.net.avaya.com (localhost [127.0.0.1])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22873
	for <sip@ietf.org>; Sat, 18 May 2002 17:46:52 -0400 (EDT)
Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16])
	by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22866
	for <sip@ietf.org>; Sat, 18 May 2002 17:46:52 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Sat, 18 May 2002 15:49:19 -0600
Message-ID: <EF4C65F18BE6464B8E9DF3C212B6B2930182A3F9@cof110avexu1.global.avaya.com>
Thread-Topic: [Sip] Asserted-Identity: How to 'hint'?
Thread-Index: AcH+KKRiRi5T8OCmROW7fHV+QiTeogAh7gTg
From: "Zmolek, Andrew (Andrew)" <zmolek@avaya.com>
To: <jh@lohi.eng.song.fi>, "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA29368
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Juha wrote:

> first, i don't like at all the idea that ietf sip working group
> discussions are dictated and constrained by 3gpp schedules.  we must
> have time to really solve the problems and not just hide them 
> under the carpet because of 3gpp.

I agree with Juha's concern here, but at the same time I have to admit that past history in the IETF around this class of problems is not encouraging, so the plausible alternatives seem worse. Regardless of how bullish one might be over 3GPP itself, it has been an effective forcing function for work that would otherwise be bogged down for years in the politics of obstructionism that have taken over so many other well-intentioned working groups around us. 

Thanks to the seemingly tireless efforts of a few members of the SIP community, we have been able to make tremendous progress in the past year (by addressing concerns head-on--not avoiding and postponing them), and if Jon is ready to take this on I'm inclined to throw more support on the side of getting this done than worry unduly about producing something less than perfect. The IETF is already quite effective at drowning most of its young in an ocean of worry and concern--it would really be quite a feat indeed to produce a runt *and* somehow sneak it by those in the IETF pledged to fight evil in all its many forms.

--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 daemon@optimus.ietf.org  Sun May 19 11:51:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11763
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 11:51:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14222
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 11:51:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13080;
	Sun, 19 May 2002 11:25:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13051
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 11:25:52 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11013
	for <sip@ietf.org>; Sun, 19 May 2002 11:25:36 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4JFPLPI002159;
	Sun, 19 May 2002 08:25:21 -0700 (PDT)
Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with SMTP id AAE25185 (AUTH rmahy);
	Sun, 19 May 2002 08:25:20 -0700 (PDT)
Message-Id: <200205191525.AAE25185@imop.cisco.com>
Received: from 171.68.225.134
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with HTTP/1.0;
	Sun, 19 May 2002 08:29:05 -0700
Date: Sun, 19 May 2002 08:29:05 -0700
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: sip@ietf.org
X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

The requirement for a hint is well understood, limited in
scope, and well motivated in the draft.  Nobody has identified
any technical reason why the hint won't work.   Your argument
that allowing a hint weakens the strength of the language on
ignoring Asserted-Identity from untrusted parties is purely
philosophical in nature.  I don't buy your argument.

thanks,
-rohan


---- Original message ----
>Date: Fri, 17 May 2002 16:02:11 -0500
>From: "Peterson, Jon" <jon.peterson@neustar.biz>  
>Subject: [Sip] Asserted-Identity: How to 'hint'?  
>To: "'sip@ietf.org'" <sip@ietf.org>
>
>
>In the course of the discussion between Mark Watson, Cullen
Jennings and
>myself about the short-term identity work, we have returned a
few times to
>the question of the infamous hint. This hint is, of course, a
way that a
>user agent (one that is not a member of the Trust Domain in
the short-term
>network asserted identity space) can provide a 'hint' to the
intermediary
>that will generate an Asserted-Identity indicating which
identity among
>several possibilities should be asserted.
>
>The need for this arises particularly from the 3G space, in
which the
>authentication process takes place independently of SIP and
does not carry
>this sort of personal identity information. It also assumes
that the
>operators of the intermediary in question are aware of
several legitimate
>identities which the user can elect to assert.
>
>It has been proposed on the mailing list and elsewhere that the
>Asserted-Identity header should be re-used by user agents
outside the Trust
>Domain to provide such a hint. I see a number of reasons for
and against
>using the Asserted-Identity for this purpose. For example,
today, there is a
>requirement that asserted-identities which are transmitted
from untrusted
>sources should not be used in any way - this would seem to
weaken that
>requirement. There is also possibly some behavior that still
needs to be
>specified (like how an intermediary would reject or otherwise
handle a
>request with an inappropriate hint) that might be impactful
to our choice.
>
>For the time being, however, I would like to suggest that
providing the hint
>is outside the scope of the current deliverables (the
asserted-identity
>requirements and mechanism drafts), which need to be
complete, as we
>discussed in the interim meeting, by the end of this month. I
believe that a
>separate draft should propose the use of Asserted-Identity or
any other
>header for this hint (in whatever timeframe is appropriate
for 3G's
>requirements), but that we should not speak to this matter in
the current
>asserted-identity deliverables. There is, as I see it, no
dependency on
>defining this hint before we dictate how intermediaries will
assert
>identities.
>
>Any comments on this plan?
>
>Jon Peterson
>NeuStar, Inc.
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Sun May 19 11:53:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11818
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 11:53:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14284
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 11:53:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12826;
	Sun, 19 May 2002 11:18:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12785
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 11:18:06 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10736
	for <sip@ietf.org>; Sun, 19 May 2002 11:17:49 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4JFHVEU023929;
	Sun, 19 May 2002 08:17:31 -0700 (PDT)
Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with SMTP id AAE25164 (AUTH rmahy);
	Sun, 19 May 2002 08:17:30 -0700 (PDT)
Message-Id: <200205191517.AAE25164@imop.cisco.com>
Received: from 171.68.225.134
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with HTTP/1.0;
	Sun, 19 May 2002 08:21:15 -0700
Date: Sun, 19 May 2002 08:21:15 -0700
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [Sip] Asserted-Identity: A P- Header?
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: sip@ietf.org
X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

I believe a P- header is consistent with the applicability
scope built into the draft.

I also feel that the cryptographic identity draft should use
the Asserted-Identity header (without the P- ).

thanks,
-rohan


---- Original message ----
>Date: Fri, 17 May 2002 17:03:25 -0500
>From: "Peterson, Jon" <jon.peterson@neustar.biz>  
>Subject: [Sip] Asserted-Identity: A P- Header?  
>To: "'sip@ietf.org'" <sip@ietf.org>
>
>
>There has been some substantial discussion in this working
group about the
>naming of the new header for the short-term network asserted
identity work.
>Although it took us some time to arrive on an agreeable name,
I'd like to
>suggest a slight modification to 'Asserted-Identity' - namely
that it become
>a P- header.
>
>P- headers are defined in the 'sipchange' draft that
discusses how
>extensions to SIP should be created. The P- is short for
'preliminary',
>'private', or 'proprietary' - and in fact, I think the
Asserted-Identity
>header for the short-term work is in fact compatible with all
three of those
>adjectives. More substantially, there are also specific
criteria for P-
>headers provided in the sipchange draft (in section 6.1) and
I believe
>Asserted-Identity is a good match for nearly all of those
criteria.
>
>sipchange says that P- headers may be appropriate when
extensions "are
>private or proprietary in nature, because a characteristic
motivating them
>is usage that is known not to fit the Internet architecture
for SIP." As an
>extension, short-term asserted identity does not define new
methods,
>responses codes, or option tags (criterion 2). The header is
purely
>informational in nature (criterion 4). Asserted-Identity also
bears a
>significant applicability statement (criterion 7). The
current draft also
>meets the constraints identified by criteria 2 and 3. I'm
sure we could get
>Expert Review as specified in criterion 1, and that the
document could be
>passed as described by criterion 6. 
>
>What do we gain by making Asserted-Identity a P- header?
Really only
>political leeway; this doesn't entail any changes to how the
header works.
>But the underlying Trust Domain model of the short-term
identity work is not
>very compatible with the Internet model, and this may very
well cause us
>some consternation moving forward this document (some
discomfiture along
>these lines was previously expressed over sip-privacy-04). By
making this
>header a P- header we can deflect this sort of criticism by
identifying this
>as work that is known to be specific to private networks that
do not adhere
>to the Internet model as such. sipchange introduced this concept
>specifically so that we could get this sort of header passed.
If we aren't
>using the P- header for this, I'm not sure what we'd use it for.
>
>One thing that I know we lose by making Asserted-Identity a
P- header is
>that the long-term identity story would no longer use the
same header name
>as the short-term identity work. However, since the interface
between
>long-term, certificate-based identity and short-term,
trust-based identity
>will be defined as a gatewaying process, we really don't
incur any cost from
>using different headers. Personally, I still feel there is
something to be
>gained by using 'From' as the header in the long-term story
(specifically,
>this jibes in certain ways with existing S/MIME behavior in
rfc3261). So I
>suppose I don't find this loss to be troubling.
>
>Thoughts?
>
>Jon Peterson
>NeuStar, Inc.
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Sun May 19 12:50:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13725
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 12:50:51 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA17496
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 12:51:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16434;
	Sun, 19 May 2002 12:27:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16392
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 12:27:44 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13173
	for <sip@ietf.org>; Sun, 19 May 2002 12:27:27 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 179TX3-0003c0-00; Sun, 19 May 2002 19:27:41 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15591.53885.740566.581104@harjus.eng.song.fi>
Date: Sun, 19 May 2002 19:27:41 +0300
To: Rohan Mahy <rohan@cisco.com>
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, sip@ietf.org
Subject: Re: [Sip] Asserted-Identity: A P- Header?
In-Reply-To: <200205191517.AAE25164@imop.cisco.com>
References: <200205191517.AAE25164@imop.cisco.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Rohan Mahy writes:

 > I believe a P- header is consistent with the applicability
 > scope built into the draft.
 >
 > I also feel that the cryptographic identity draft should use
 > the Asserted-Identity header (without the P- ).

i don't see the point of having two headers for the same purpose, one
with P and one without just in order to meet some 3gpp deadline.

-- 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 daemon@optimus.ietf.org  Sun May 19 13:40:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15192
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 13:40:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA20734
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 13:40:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19114;
	Sun, 19 May 2002 13:11:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19083
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 13:11:44 -0400 (EDT)
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14349
	for <sip@ietf.org>; Sun, 19 May 2002 13:11:27 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4JHB1I15796;
	Sun, 19 May 2002 12:11:01 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZS857>; Sun, 19 May 2002 12:10:56 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870328@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Rohan Mahy'" <rohan@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Sun, 19 May 2002 12:10:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


My argument was not that the proposed hint won't work - just that it isn't
necessary to solve the problem at hand. It might not be the case that the
problems with the hint stop at the philosophical point you mention below.
What I asked in my last mail was not whether or not we needed a hint, but
rather whether or not we should table that question until we resolve the
other questions at hand. I just don't want to spend the cycles arguing about
the hint given our very aggressive timetable - frankly, I think that
reaching consensus on this hint matter might push back our dates a bit.
Let's investigate this hint stuff in June, but for now just figure out how a
Trust Domain can manage an asserted identity in a message.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Sunday, May 19, 2002 8:29 AM
> To: Peterson, Jon
> Cc: sip@ietf.org
> Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> Hi,
> 
> The requirement for a hint is well understood, limited in
> scope, and well motivated in the draft.  Nobody has identified
> any technical reason why the hint won't work.   Your argument
> that allowing a hint weakens the strength of the language on
> ignoring Asserted-Identity from untrusted parties is purely
> philosophical in nature.  I don't buy your argument.
> 
> thanks,
> -rohan
> 
> 
> ---- Original message ----
> >Date: Fri, 17 May 2002 16:02:11 -0500
> >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> >To: "'sip@ietf.org'" <sip@ietf.org>
> >
> >
> >In the course of the discussion between Mark Watson, Cullen
> Jennings and
> >myself about the short-term identity work, we have returned a
> few times to
> >the question of the infamous hint. This hint is, of course, a
> way that a
> >user agent (one that is not a member of the Trust Domain in
> the short-term
> >network asserted identity space) can provide a 'hint' to the
> intermediary
> >that will generate an Asserted-Identity indicating which
> identity among
> >several possibilities should be asserted.
> >
> >The need for this arises particularly from the 3G space, in
> which the
> >authentication process takes place independently of SIP and
> does not carry
> >this sort of personal identity information. It also assumes
> that the
> >operators of the intermediary in question are aware of
> several legitimate
> >identities which the user can elect to assert.
> >
> >It has been proposed on the mailing list and elsewhere that the
> >Asserted-Identity header should be re-used by user agents
> outside the Trust
> >Domain to provide such a hint. I see a number of reasons for
> and against
> >using the Asserted-Identity for this purpose. For example,
> today, there is a
> >requirement that asserted-identities which are transmitted
> from untrusted
> >sources should not be used in any way - this would seem to
> weaken that
> >requirement. There is also possibly some behavior that still
> needs to be
> >specified (like how an intermediary would reject or otherwise
> handle a
> >request with an inappropriate hint) that might be impactful
> to our choice.
> >
> >For the time being, however, I would like to suggest that
> providing the hint
> >is outside the scope of the current deliverables (the
> asserted-identity
> >requirements and mechanism drafts), which need to be
> complete, as we
> >discussed in the interim meeting, by the end of this month. I
> believe that a
> >separate draft should propose the use of Asserted-Identity or
> any other
> >header for this hint (in whatever timeframe is appropriate
> for 3G's
> >requirements), but that we should not speak to this matter in
> the current
> >asserted-identity deliverables. There is, as I see it, no
> dependency on
> >defining this hint before we dictate how intermediaries will
> assert
> >identities.
> >
> >Any comments on this plan?
> >
> >Jon Peterson
> >NeuStar, Inc.
> >
> >_______________________________________________
> >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Sun May 19 14:27:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16825
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 14:27:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA23217
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 14:27:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21545;
	Sun, 19 May 2002 13:58:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21517
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 13:58:51 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15816
	for <sip@ietf.org>; Sun, 19 May 2002 13:58:33 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 179UxF-0003dm-00; Sun, 19 May 2002 20:58:49 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15591.59353.341736.922912@harjus.eng.song.fi>
Date: Sun, 19 May 2002 20:58:49 +0300
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
In-Reply-To: <70565611B164D511957A001083FCDD5601870328@va02.va.neustar.com>
References: <70565611B164D511957A001083FCDD5601870328@va02.va.neustar.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Peterson, Jon writes:

 > My argument was not that the proposed hint won't work - just that it isn't
 > necessary to solve the problem at hand. 

i don't know what problem you have in hand, but i definitely need the
hint to solve the problem that i (and anyone who gateways sip calls to
pstn) has in hand: i need a hint header, when i can't use the uri in the
from header as the hint, i.e., when the from is anonymous.

if the intention of the sip working group is only to solve 3gpp problems
and ignore the generic problems, then we either need another working
group or the 3gpp folks have to solve their problems somewhere else.
the area directors might be able to give a hint what we should do.

-- 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 daemon@optimus.ietf.org  Sun May 19 22:00:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04626
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 22:00:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA19785
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 22:00:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17705;
	Sun, 19 May 2002 21:27:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17669
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 21:27:27 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03210
	for <sip@ietf.org>; Sun, 19 May 2002 21:27:08 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4K1QtPI015904;
	Sun, 19 May 2002 18:26:55 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACY38567;
	Sun, 19 May 2002 18:27:06 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <jh@lohi.eng.song.fi>, "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Sun, 19 May 2002 18:27:29 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCEEDKCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <15591.59353.341736.922912@harjus.eng.song.fi>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I'm not really sure what you see as the problem at hand - I'm just guessing,
but ... If the Gateway was part of the Trust Domain, I think you can solve
the problem you want without the hint. If the GW is not part of the Trust
Domain then I don't see even how the hint will really help if all the
elements act as required.

Cullen


> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> jh@lohi.eng.song.fi
> Sent: Sunday, May 19, 2002 10:59 AM
> To: Peterson, Jon
> Cc: 'Rohan Mahy'; sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
>
>
> Peterson, Jon writes:
>
>  > My argument was not that the proposed hint won't work - just
> that it isn't
>  > necessary to solve the problem at hand.
>
> i don't know what problem you have in hand, but i definitely need the
> hint to solve the problem that i (and anyone who gateways sip calls to
> pstn) has in hand: i need a hint header, when i can't use the uri in the
> from header as the hint, i.e., when the from is anonymous.
>
> if the intention of the sip working group is only to solve 3gpp problems
> and ignore the generic problems, then we either need another working
> group or the 3gpp folks have to solve their problems somewhere else.
> the area directors might be able to give a hint what we should do.
>
> -- 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 daemon@optimus.ietf.org  Sun May 19 22:51:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07205
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 22:51:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA22079
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 22:51:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20695;
	Sun, 19 May 2002 22:27:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20666
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 22:27:47 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05857
	for <sip@ietf.org>; Sun, 19 May 2002 22:27:28 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4K2RFHs010410;
	Sun, 19 May 2002 19:27:15 -0700 (PDT)
Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with SMTP id AAE26828 (AUTH rmahy);
	Sun, 19 May 2002 19:27:14 -0700 (PDT)
Message-Id: <200205200227.AAE26828@imop.cisco.com>
Received: from 171.68.225.134
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with HTTP/1.0;
	Sun, 19 May 2002 19:31:04 -0700
Date: Sun, 19 May 2002 19:31:04 -0700
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [Sip] draft-mahy-sipping-join-and-fork-00
To: Victor Paulsamy <victor@zapex.com>
Cc: sip@ietf.org
X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

Party "A" might find the dialog information for a Join from an
out of band mechanism like a web page, embedded in a Refer-To
header in a REFER request, or from some appropriate event
package.  (there may be other reasonable ways to get this info
as well).

An appropriate event package will be resubmitted as a SIPPING
WG item soon, but is available as an individual draft now as:

draft-rosenberg-sip-call-package-01.txt

discussion on the two event packages in this draft takes place
on the SIPPING WG list:  sipping@ietf.org

hope this helps.
thanks,
-rohan


---- Original message ----
>Date: Tue, 14 May 2002 18:02:42 -0700
>From: "Victor Paulsamy" <victor@zapex.com>  
>Subject: [Sip] draft-mahy-sipping-join-and-fork-00  
>To: <sip@ietf.org>
>Cc: <rohan@cisco.com>, "Victor Paulsamy" <victor@zapex.com>
>
>In e.g., 6.1 Join accepted for local mixing: B&C are in a
session. A sends
>in an INVITE to B requesting it to add to the existing
session (using Join).
>How did A learn about the on going session?
>
>Appreciate any response.
>
>Regards,
>
>--victor
>
>Victor Paulsamy               E-mail: victor@zapex.com
>Senior Software Engineer      Phone : 650.930.1339 (Direct)
>Zapex Technologies, Inc.      Phone : 650.930.1300 (Main)
>Mountain View, CA 94043       Fax   : 650.930.1399
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Sun May 19 23:07:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08239
	for <sip-archive@odin.ietf.org>; Sun, 19 May 2002 23:07:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA23338
	for sip-archive@odin.ietf.org; Sun, 19 May 2002 23:07:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21826;
	Sun, 19 May 2002 22:44:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA21790
	for <sip@optimus.ietf.org>; Sun, 19 May 2002 22:44:00 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06761
	for <sip@ietf.org>; Sun, 19 May 2002 22:43:40 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4K2hRPI003185;
	Sun, 19 May 2002 19:43:27 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACY38931;
	Sun, 19 May 2002 19:43:39 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <jh@lohi.eng.song.fi>, "Rohan Mahy" <rohan@cisco.com>
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, <sip@ietf.org>
Subject: RE: [Sip] Asserted-Identity: A P- Header?
Date: Sun, 19 May 2002 19:44:02 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCKEDKCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <15591.53885.740566.581104@harjus.eng.song.fi>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I don't think the P-Header issue has much to do with 3GPP.

The non cryptographic (AKA short term) Asserted-Identity work has a limited
scope of applicability - It is not usable in the circumstances we might call
the general internet. The way the requirements draft limits where it can be
used, and the other agreements that it have to be in place for it to work,
is what makes it seem like it lines up with the intent of a P-Header.

The cryptographic solution (AKA long term) stuff does not have these
limitations and thus would not require a P-Header.

It's not clear to me yet, but having it this way might turn out to be very
advantageous when building nodes that understand both the crypto and non
crypto solutions and need to pass information from one type of domain to
another.

Cullen


> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> jh@lohi.eng.song.fi
> Sent: Sunday, May 19, 2002 9:28 AM
> To: Rohan Mahy
> Cc: Peterson, Jon; sip@ietf.org
> Subject: Re: [Sip] Asserted-Identity: A P- Header?
>
>
> Rohan Mahy writes:
>
>  > I believe a P- header is consistent with the applicability
>  > scope built into the draft.
>  >
>  > I also feel that the cryptographic identity draft should use
>  > the Asserted-Identity header (without the P- ).
>
> i don't see the point of having two headers for the same purpose, one
> with P and one without just in order to meet some 3gpp deadline.
>
> -- 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 daemon@optimus.ietf.org  Mon May 20 00:42:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13255
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 00:42:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA28359
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 00:42:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27139;
	Mon, 20 May 2002 00:19:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA27104
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 00:19:39 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11599
	for <sip@ietf.org>; Mon, 20 May 2002 00:19:21 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 179ee0-0003lq-00; Mon, 20 May 2002 07:19:36 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15592.31064.107813.518993@harjus.eng.song.fi>
Date: Mon, 20 May 2002 07:19:36 +0300
To: "Cullen Jennings" <fluffy@cisco.com>
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>,
        "'Rohan Mahy'" <rohan@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
In-Reply-To: <DLEHICEBMNEIPCACNLPCEEDKCDAA.fluffy@cisco.com>
References: <15591.59353.341736.922912@harjus.eng.song.fi>
	<DLEHICEBMNEIPCACNLPCEEDKCDAA.fluffy@cisco.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Cullen Jennings writes:

 > I'm not really sure what you see as the problem at hand - I'm just guessing,
 > but ... If the Gateway was part of the Trust Domain, I think you can solve
 > the problem you want without the hint.

no, i can't because the user almost always has multiple sip identities
and thus, in the anonymous case, needs to hint the trust domain which
identity he/she wants to use for the call.

-- 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 daemon@optimus.ietf.org  Mon May 20 05:35:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02131
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 05:35:29 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA20402
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 05:35:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19376;
	Mon, 20 May 2002 05:13:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA19347
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 05:13:32 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01404
	for <sip@ietf.org>; Mon, 20 May 2002 05:13:13 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4K9Dmk18741
	for <sip@ietf.org>; Mon, 20 May 2002 12:13:48 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5afa348df2ac158f22077@esvir02nok.ntc.nokia.com>;
 Mon, 20 May 2002 12:13:24 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 20 May 2002 12:13:24 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 20 May 2002 12:13:24 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED11@esebe013.NOE.Nokia.com>
Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Thread-Index: AcH96D4X/9oors2jSqyKRzzY7RPyWgB8oXFg
To: <bcampbell@dynamicsoft.com>, <hgs@cs.columbia.edu>, <mat@cisco.com>,
        <dean.willis@softarmor.com>, <jdrosen@dynamicsoft.com>,
        <seancolson@yahoo.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 20 May 2002 09:13:24.0823 (UTC) FILETIME=[986DA670:01C1FFDE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA19348
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

If #2 is in any way possible, let's pursue that. Reading the bis-09 again, I can't help but wonder if the RFC2543 option of still trying with UDP, if TCP has failed actually provides value for messages over the UDP maximum datagram size of 65,535 bytes.

If there was a SHOULD in trying UDP when TCP fails, but a SHOULD NOT if size is over 65k, would the MESSAGE then be more well behaved? I.e., enough to be able to relax the size limit to a SHOULD strength in the message draft?

Otherwise, I'm ready to live with #2, given that the text is changed to align with bis-09 (MESSAGE talks about payload size, whereas bis-09 talks about request size), and provide with a way to send larger messages if there is a transport with congestion control all the way to the destination.

Cheers,
Aki

 

> -----Original Message-----
> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Saturday, May 18, 2002 12:17 AM
> To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan
> Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo)
> Cc: sip@ietf.org
> Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
> 
> 
> OK, to summarize where I think we are, I have seen 4 
> proposals for dealing
> with the message size controversy:
> 
> 1) Just live with it. IM's are not designed to carry large 
> content anyway.
> Large content should be sent using some other mechanism, like 
> in-session
> messages, content indirection, or something completely 
> different like email.
> (bottom line: limit stays, with perhaps a clarification of 
> the how the limit
> relates to the lowest hop MTU.)
> 
> 2) Fix the SIP "feature" that creates this problem in the 
> first place, i.e.
> the fact that a proxy can fail over to UDP even when a 
> congestion controlled
> transport is requested. Jonathan suggested dissallowing this 
> proxy behavior
> for large content messages. I'm not sure how hard that charge 
> would be to
> get into 3261.
> 
> 3) Adding something like a proxy-require:contestion-safe tag, 
> so that the
> UAC can insist on end-to-end congestion control. This of 
> course means that
> large content MESSAGE requests could not pass _any_ existing 
> proxies--but
> that is no more limiting than saying you can't have large 
> content messages
> at all. It at least gives us a way to relax the limit if we 
> someday do get
> proxies that support the tag.
> 
> 4) Relax the limit back to a should, but take no further 
> action. I do not
> think that would pass IESG muster at this point.
> 
> Personally I lean towards option 1. Pager model IMs are really _not_
> intended to be a file transfer mechanism. Even without a 
> strict limit, I
> think that large content messages (where content is 
> physically carried in
> the message) are a misuse of the mechanism. We should work to 
> specify an
> indirect-content mechanism, a session based mechanism, or 
> both. But those
> are out of scope for pager model messaging, and should not become a
> dependency for this draft. Option 4 is pretty much out of the 
> question. 2 &
> 3 may be doable, but are significant enough that we might 
> need to re-cycle
> the last call.
> 
> This really seems to be a full circle discussion, back to 
> IMPP requirements
> days. I think our best bet is to narrow the scope to something
> solveable--that is short text (or otherwise small content) 
> instant messages,
> solve that, then work on more sophisticated mechanisms for 
> large content.
> 
> Thoughts?
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Friday, May 17, 2002 2:51 PM
> > To: Michael Thomas
> > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell';
> > aki.niemi@nokia.com; sip@ietf.org
> > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
> > changes)
> >
> >
> > Joking aside, this may not be such a bad idea: Send an IM 
> with a message
> > reference, with email sent simultaneously. Generally, mail 
> delivery is
> > measured in seconds (and for the long messages we're 
> talking about here,
> > any processing delays would tend to be overwhelmed by 
> transport delays).
> > Avoids all firewall, cable modem restriction and NAT issues and, to
> > boot, leverages off the likelihood that SIP and SMTP address are the
> > same. Plus, with IMAP, the client already gets to decide whether to
> > download attachments or not.
> >
> > Michael Thomas wrote:
> > > Dean Willis writes:
> > >  >
> > >  > One must ask -- at what point should one transition from IM to
> > >  > email?
> > >
> > >    Immediately?
> 
> 

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



From daemon@optimus.ietf.org  Mon May 20 07:35:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07065
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 07:35:55 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA26860
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 07:36:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25037;
	Mon, 20 May 2002 07:09:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA25007
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 07:09:05 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05909
	for <sip@ietf.org>; Mon, 20 May 2002 07:08:48 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4KB8RZ24043;
	Mon, 20 May 2002 13:08:27 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4KB7d210408;
	Mon, 20 May 2002 12:07:40 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <L1AJR1S2>; Mon, 20 May 2002 12:08:37 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7253@zwcwd00r.europe.nortel.com>
From: "Mark Watson"<mwatson@nortelnetworks.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Rohan Mahy'"
	 <rohan@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Mon, 20 May 2002 12:08:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1FFEE.A9A13BE0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

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

The 'hint' was one of the three requirements that 3GPP communicated to us in
April.

It is a separate requirement from the Network Asserted Identity itself, and
so is not addressed in the requirements draft, although I have been careful
to point this out, and to point out that it is a requirement nontheless, on
several occasions.

I believe we need the 'hint' in the same timeframe as the rest of the short
term work.

Whether it is the same header/draft or a different header/draft is another
question on which I will only say that we'd better make up our minds pretty
quick.

...Mark


> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: 19 May 2002 18:11
> To: 'Rohan Mahy'
> Cc: sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> 
> My argument was not that the proposed hint won't work - just 
> that it isn't
> necessary to solve the problem at hand. It might not be the 
> case that the
> problems with the hint stop at the philosophical point you 
> mention below.
> What I asked in my last mail was not whether or not we needed 
> a hint, but
> rather whether or not we should table that question until we 
> resolve the
> other questions at hand. I just don't want to spend the 
> cycles arguing about
> the hint given our very aggressive timetable - frankly, I think that
> reaching consensus on this hint matter might push back our 
> dates a bit.
> Let's investigate this hint stuff in June, but for now just 
> figure out how a
> Trust Domain can manage an asserted identity in a message.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan@cisco.com]
> > Sent: Sunday, May 19, 2002 8:29 AM
> > To: Peterson, Jon
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
> > 
> > 
> > Hi,
> > 
> > The requirement for a hint is well understood, limited in
> > scope, and well motivated in the draft.  Nobody has identified
> > any technical reason why the hint won't work.   Your argument
> > that allowing a hint weakens the strength of the language on
> > ignoring Asserted-Identity from untrusted parties is purely
> > philosophical in nature.  I don't buy your argument.
> > 
> > thanks,
> > -rohan
> > 
> > 
> > ---- Original message ----
> > >Date: Fri, 17 May 2002 16:02:11 -0500
> > >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > >To: "'sip@ietf.org'" <sip@ietf.org>
> > >
> > >
> > >In the course of the discussion between Mark Watson, Cullen
> > Jennings and
> > >myself about the short-term identity work, we have returned a
> > few times to
> > >the question of the infamous hint. This hint is, of course, a
> > way that a
> > >user agent (one that is not a member of the Trust Domain in
> > the short-term
> > >network asserted identity space) can provide a 'hint' to the
> > intermediary
> > >that will generate an Asserted-Identity indicating which
> > identity among
> > >several possibilities should be asserted.
> > >
> > >The need for this arises particularly from the 3G space, in
> > which the
> > >authentication process takes place independently of SIP and
> > does not carry
> > >this sort of personal identity information. It also assumes
> > that the
> > >operators of the intermediary in question are aware of
> > several legitimate
> > >identities which the user can elect to assert.
> > >
> > >It has been proposed on the mailing list and elsewhere that the
> > >Asserted-Identity header should be re-used by user agents
> > outside the Trust
> > >Domain to provide such a hint. I see a number of reasons for
> > and against
> > >using the Asserted-Identity for this purpose. For example,
> > today, there is a
> > >requirement that asserted-identities which are transmitted
> > from untrusted
> > >sources should not be used in any way - this would seem to
> > weaken that
> > >requirement. There is also possibly some behavior that still
> > needs to be
> > >specified (like how an intermediary would reject or otherwise
> > handle a
> > >request with an inappropriate hint) that might be impactful
> > to our choice.
> > >
> > >For the time being, however, I would like to suggest that
> > providing the hint
> > >is outside the scope of the current deliverables (the
> > asserted-identity
> > >requirements and mechanism drafts), which need to be
> > complete, as we
> > >discussed in the interim meeting, by the end of this month. I
> > believe that a
> > >separate draft should propose the use of Asserted-Identity or
> > any other
> > >header for this hint (in whatever timeframe is appropriate
> > for 3G's
> > >requirements), but that we should not speak to this matter in
> > the current
> > >asserted-identity deliverables. There is, as I see it, no
> > dependency on
> > >defining this hint before we dictate how intermediaries will
> > assert
> > >identities.
> > >
> > >Any comments on this plan?
> > >
> > >Jon Peterson
> > >NeuStar, Inc.
> > >
> > >_______________________________________________
> > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > >This list is for NEW development of the core SIP 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
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Sip] Asserted-Identity: How to 'hint'?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The 'hint' was one of the three requirements that =
3GPP communicated to us in April.</FONT>
</P>

<P><FONT SIZE=3D2>It is a separate requirement from the Network =
Asserted Identity itself, and so is not addressed in the requirements =
draft, although I have been careful to point this out, and to point out =
that it is a requirement nontheless, on several occasions.</FONT></P>

<P><FONT SIZE=3D2>I believe we need the 'hint' in the same timeframe as =
the rest of the short term work.</FONT>
</P>

<P><FONT SIZE=3D2>Whether it is the same header/draft or a different =
header/draft is another question on which I will only say that we'd =
better make up our minds pretty quick.</FONT></P>

<P><FONT SIZE=3D2>...Mark</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Peterson, Jon [<A =
HREF=3D"mailto:jon.peterson@neustar.biz">mailto:jon.peterson@neustar.biz=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 19 May 2002 18:11</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Rohan Mahy'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Sip] Asserted-Identity: How to =
'hint'?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My argument was not that the proposed hint =
won't work - just </FONT>
<BR><FONT SIZE=3D2>&gt; that it isn't</FONT>
<BR><FONT SIZE=3D2>&gt; necessary to solve the problem at hand. It =
might not be the </FONT>
<BR><FONT SIZE=3D2>&gt; case that the</FONT>
<BR><FONT SIZE=3D2>&gt; problems with the hint stop at the =
philosophical point you </FONT>
<BR><FONT SIZE=3D2>&gt; mention below.</FONT>
<BR><FONT SIZE=3D2>&gt; What I asked in my last mail was not whether or =
not we needed </FONT>
<BR><FONT SIZE=3D2>&gt; a hint, but</FONT>
<BR><FONT SIZE=3D2>&gt; rather whether or not we should table that =
question until we </FONT>
<BR><FONT SIZE=3D2>&gt; resolve the</FONT>
<BR><FONT SIZE=3D2>&gt; other questions at hand. I just don't want to =
spend the </FONT>
<BR><FONT SIZE=3D2>&gt; cycles arguing about</FONT>
<BR><FONT SIZE=3D2>&gt; the hint given our very aggressive timetable - =
frankly, I think that</FONT>
<BR><FONT SIZE=3D2>&gt; reaching consensus on this hint matter might =
push back our </FONT>
<BR><FONT SIZE=3D2>&gt; dates a bit.</FONT>
<BR><FONT SIZE=3D2>&gt; Let's investigate this hint stuff in June, but =
for now just </FONT>
<BR><FONT SIZE=3D2>&gt; figure out how a</FONT>
<BR><FONT SIZE=3D2>&gt; Trust Domain can manage an asserted identity in =
a message.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Jon Peterson</FONT>
<BR><FONT SIZE=3D2>&gt; NeuStar, Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Rohan Mahy [<A =
HREF=3D"mailto:rohan@cisco.com">mailto:rohan@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Sunday, May 19, 2002 8:29 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Peterson, Jon</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: [Sip] Asserted-Identity: How =
to 'hint'?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The requirement for a hint is well =
understood, limited in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; scope, and well motivated in the =
draft.&nbsp; Nobody has identified</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; any technical reason why the hint won't =
work.&nbsp;&nbsp; Your argument</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that allowing a hint weakens the strength =
of the language on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ignoring Asserted-Identity from untrusted =
parties is purely</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; philosophical in nature.&nbsp; I don't buy =
your argument.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -rohan</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ---- Original message ----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Date: Fri, 17 May 2002 16:02:11 =
-0500</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;From: &quot;Peterson, Jon&quot; =
&lt;jon.peterson@neustar.biz&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Subject: [Sip] Asserted-Identity: How =
to 'hint'?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;To: &quot;'sip@ietf.org'&quot; =
&lt;sip@ietf.org&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;In the course of the discussion =
between Mark Watson, Cullen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Jennings and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;myself about the short-term identity =
work, we have returned a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; few times to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;the question of the infamous hint. =
This hint is, of course, a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; way that a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;user agent (one that is not a member =
of the Trust Domain in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the short-term</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;network asserted identity space) can =
provide a 'hint' to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; intermediary</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;that will generate an =
Asserted-Identity indicating which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; identity among</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;several possibilities should be =
asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;The need for this arises particularly =
from the 3G space, in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; which the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;authentication process takes place =
independently of SIP and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; does not carry</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;this sort of personal identity =
information. It also assumes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;operators of the intermediary in =
question are aware of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; several legitimate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;identities which the user can elect to =
assert.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;It has been proposed on the mailing =
list and elsewhere that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Asserted-Identity header should be =
re-used by user agents</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; outside the Trust</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Domain to provide such a hint. I see a =
number of reasons for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and against</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;using the Asserted-Identity for this =
purpose. For example,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; today, there is a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;requirement that asserted-identities =
which are transmitted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; from untrusted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;sources should not be used in any way =
- this would seem to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; weaken that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;requirement. There is also possibly =
some behavior that still</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; needs to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;specified (like how an intermediary =
would reject or otherwise</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; handle a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;request with an inappropriate hint) =
that might be impactful</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to our choice.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;For the time being, however, I would =
like to suggest that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; providing the hint</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;is outside the scope of the current =
deliverables (the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; asserted-identity</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;requirements and mechanism drafts), =
which need to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; complete, as we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;discussed in the interim meeting, by =
the end of this month. I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; believe that a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;separate draft should propose the use =
of Asserted-Identity or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; any other</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;header for this hint (in whatever =
timeframe is appropriate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for 3G's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;requirements), but that we should not =
speak to this matter in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the current</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;asserted-identity deliverables. There =
is, as I see it, no</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; dependency on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;defining this hint before we dictate =
how intermediaries will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; assert</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;identities.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Any comments on this plan?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Jon Peterson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;NeuStar, Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;This list is for NEW development of =
the core SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Use sip-implementors@cs.columbia.edu =
for questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Use sipping@ietf.org for new =
developments on the application</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; of sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1FFEE.A9A13BE0--

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



From daemon@optimus.ietf.org  Mon May 20 08:13:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09748
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 08:13:52 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA29645
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 08:14:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28017;
	Mon, 20 May 2002 07:55:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA27986
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 07:55:25 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08329;
	Mon, 20 May 2002 07:55:05 -0400 (EDT)
Message-Id: <200205201155.HAA08329@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Mon, 20 May 2002 07:55:05 -0400
Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIP Extension Header Field for Service Route Discovery
                          in Private Networks
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-scvrtdisco-04.txt
	Pages		: 15
	Date		: 17-May-02
	
This document proposes a private SIP extension header used in
conjunction with responses to REGISTER messages to provide a
mechanism by which a registrar may inform a registering UA of a
service route that the UA may use to request outbound services from
the registrar's domain.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-willis-sip-scvrtdisco-04.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-willis-sip-scvrtdisco-04.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:	<20020517135143.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-willis-sip-scvrtdisco-04.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Mon May 20 09:44:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16447
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 09:44:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA05468
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 09:44:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03509;
	Mon, 20 May 2002 09:17:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03455
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 09:17:29 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13834
	for <sip@ietf.org>; Mon, 20 May 2002 09:17:09 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4KDGVX54642;
	Mon, 20 May 2002 08:16:33 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: <aki.niemi@nokia.com>, <hgs@cs.columbia.edu>, <mat@cisco.com>,
        <dean.willis@softarmor.com>, <jdrosen@dynamicsoft.com>,
        <seancolson@yahoo.com>
Cc: <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Mon, 20 May 2002 08:16:19 -0500
Message-ID: <HNEOJECGFHIABDLENMMCKEACCJAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED11@esebe013.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Would you expect the MESSAGE draft to stall waiting for a 3261 fix? 

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Monday, May 20, 2002 4:13 AM
> To: bcampbell@dynamicsoft.com; hgs@cs.columbia.edu; mat@cisco.com;
> dean.willis@softarmor.com; jdrosen@dynamicsoft.com; seancolson@yahoo.com
> Cc: sip@ietf.org
> Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
> 
> 
> Hi,
> 
> If #2 is in any way possible, let's pursue that. Reading the 
> bis-09 again, I can't help but wonder if the RFC2543 option of 
> still trying with UDP, if TCP has failed actually provides value 
> for messages over the UDP maximum datagram size of 65,535 bytes.
> 
> If there was a SHOULD in trying UDP when TCP fails, but a SHOULD 
> NOT if size is over 65k, would the MESSAGE then be more well 
> behaved? I.e., enough to be able to relax the size limit to a 
> SHOULD strength in the message draft?
> 
> Otherwise, I'm ready to live with #2, given that the text is 
> changed to align with bis-09 (MESSAGE talks about payload size, 
> whereas bis-09 talks about request size), and provide with a way 
> to send larger messages if there is a transport with congestion 
> control all the way to the destination.
> 
> Cheers,
> Aki
> 
>  
> 
> > -----Original Message-----
> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> > Sent: Saturday, May 18, 2002 12:17 AM
> > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan
> > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo)
> > Cc: sip@ietf.org
> > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> > changes)
> > 
> > 
> > OK, to summarize where I think we are, I have seen 4 
> > proposals for dealing
> > with the message size controversy:
> > 
> > 1) Just live with it. IM's are not designed to carry large 
> > content anyway.
> > Large content should be sent using some other mechanism, like 
> > in-session
> > messages, content indirection, or something completely 
> > different like email.
> > (bottom line: limit stays, with perhaps a clarification of 
> > the how the limit
> > relates to the lowest hop MTU.)
> > 
> > 2) Fix the SIP "feature" that creates this problem in the 
> > first place, i.e.
> > the fact that a proxy can fail over to UDP even when a 
> > congestion controlled
> > transport is requested. Jonathan suggested dissallowing this 
> > proxy behavior
> > for large content messages. I'm not sure how hard that charge 
> > would be to
> > get into 3261.
> > 
> > 3) Adding something like a proxy-require:contestion-safe tag, 
> > so that the
> > UAC can insist on end-to-end congestion control. This of 
> > course means that
> > large content MESSAGE requests could not pass _any_ existing 
> > proxies--but
> > that is no more limiting than saying you can't have large 
> > content messages
> > at all. It at least gives us a way to relax the limit if we 
> > someday do get
> > proxies that support the tag.
> > 
> > 4) Relax the limit back to a should, but take no further 
> > action. I do not
> > think that would pass IESG muster at this point.
> > 
> > Personally I lean towards option 1. Pager model IMs are really _not_
> > intended to be a file transfer mechanism. Even without a 
> > strict limit, I
> > think that large content messages (where content is 
> > physically carried in
> > the message) are a misuse of the mechanism. We should work to 
> > specify an
> > indirect-content mechanism, a session based mechanism, or 
> > both. But those
> > are out of scope for pager model messaging, and should not become a
> > dependency for this draft. Option 4 is pretty much out of the 
> > question. 2 &
> > 3 may be doable, but are significant enough that we might 
> > need to re-cycle
> > the last call.
> > 
> > This really seems to be a full circle discussion, back to 
> > IMPP requirements
> > days. I think our best bet is to narrow the scope to something
> > solveable--that is short text (or otherwise small content) 
> > instant messages,
> > solve that, then work on more sophisticated mechanisms for 
> > large content.
> > 
> > Thoughts?
> > 
> > > -----Original Message-----
> > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > Sent: Friday, May 17, 2002 2:51 PM
> > > To: Michael Thomas
> > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben Campbell';
> > > aki.niemi@nokia.com; sip@ietf.org
> > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
> > > changes)
> > >
> > >
> > > Joking aside, this may not be such a bad idea: Send an IM 
> > with a message
> > > reference, with email sent simultaneously. Generally, mail 
> > delivery is
> > > measured in seconds (and for the long messages we're 
> > talking about here,
> > > any processing delays would tend to be overwhelmed by 
> > transport delays).
> > > Avoids all firewall, cable modem restriction and NAT issues and, to
> > > boot, leverages off the likelihood that SIP and SMTP address are the
> > > same. Plus, with IMAP, the client already gets to decide whether to
> > > download attachments or not.
> > >
> > > Michael Thomas wrote:
> > > > Dean Willis writes:
> > > >  >
> > > >  > One must ask -- at what point should one transition from IM to
> > > >  > email?
> > > >
> > > >    Immediately?
> > 
> > 

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



From daemon@optimus.ietf.org  Mon May 20 10:13:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23281
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 10:13:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA07317
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 10:13:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06220;
	Mon, 20 May 2002 09:58:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA06187
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 09:58:42 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19260
	for <sip@ietf.org>; Mon, 20 May 2002 09:58:24 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id AF30E2AA0154; Mon, 20 May 2002 09:50:40 -0400
Message-ID: <002d01c20005$77bff320$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <dunc.mills@btinternet.com>, <sip@ietf.org>,
        <duncan.mills@vf.vodafone.co.uk>
References: <3409234.1021473697235.JavaMail.root@127.0.0.1>
Subject: Re: [Sip] I-D ACTION:draft-mills-sip-access-network-info-01.txt
Date: Mon, 20 May 2002 09:51:40 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

----- Original Message -----
>From: <dunc.mills@btinternet.com>
>
>Bob,
>
>Many thanks for your comments.  It is re-assuring to know that some IETF
>experts have reviewed my draft.
>
>Please consider my comments below.  I look forward to your further input,
>if necessary.
>
>Regards,
>
>Duncan
>
<snip>
>>2) Does this draft need an explicit Applicability Statement?
>>
>I think the draft could be applicable to various systems,
>but obviously I am writing it primarily with a 3GPP
>requirement in mind.  Do you think I need to add an
>explicit Applicability Statement?  My IETF procedural
>knowledge is (I'm afraid) limited.
>
Almost all of the other P-header proposals include one. I think due to the
special circumstances required for this header, there needs to be one. I
think it is just a matter of organizing all of the applicability information
you already have into a formal Applicability Statement section.


<snip>
>>8) Section 7.2 is labeled "UAS behavior", but talks only about proxy
>>behavior. I don't think there is any UAS behavior for this header.
>
>Does 'Proxy behaviour' cover the case of a B2BUA?
>
There is no mention of a B2BUA, and I don't see anything in this draft would
turn a proxy into a B2BUA. In any event, you are talking about an
intermediary (proxy, B2BUA, or whatever you call it) as opposed to an
endpoint. It seems to me both 7.2 and 7.3 are talking about the same thing.

cheers,
(-:bob


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



From daemon@optimus.ietf.org  Mon May 20 10:43:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00727
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 10:43:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA08888
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 10:43:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07556;
	Mon, 20 May 2002 10:18:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07514
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 10:18:29 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24711
	for <sip@ietf.org>; Mon, 20 May 2002 10:18:10 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4KEHIY11214
	for <sip@ietf.org>; Mon, 20 May 2002 17:17:18 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5afb4bd286ac158f25079@esvir05nok.ntc.nokia.com>;
 Mon, 20 May 2002 17:18:26 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 20 May 2002 17:18:26 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 20 May 2002 17:18:26 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED19@esebe013.NOE.Nokia.com>
Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Thread-Index: AcIAAJVjwDo6S7OdTsaJp7pxQXr5jQAAeBmA
To: <bcampbell@dynamicsoft.com>, <hgs@cs.columbia.edu>, <mat@cisco.com>,
        <dean.willis@softarmor.com>, <jdrosen@dynamicsoft.com>,
        <seancolson@yahoo.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 20 May 2002 14:18:26.0813 (UTC) FILETIME=[3543B2D0:01C20009]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA07515
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> Would you expect the MESSAGE draft to stall waiting for a 3261 fix? 

If you're talking about another draft-ietf-sip-rfc3261bis cycle, certainly not.

But (a) since RFC 3261 hasn't actually been published yet, I imagine a "fix" could sneak in even in such a late stage. Of course not being that familiar with the IETF process this may be daydreaming, but I was under the impression that even though undesireable, changes may be considered even to documents that have been approved by the IESG.

Another issue is, that (b) would a fix such as the one described by the post below actually properly fulfill the requirements for congestion control of MESSAGEs.

If both (a) and (b) aren't going to be reality, I will shut my mouth for now, save my comments for whichever documents will update the protocol in the future, and be perfectly happy with #1, as long as the text is aligned with bis-09 on the relevant parts.

Cheers,
Aki

> 
> > -----Original Message-----
> > From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> > Sent: Monday, May 20, 2002 4:13 AM
> > To: bcampbell@dynamicsoft.com; hgs@cs.columbia.edu; mat@cisco.com;
> > dean.willis@softarmor.com; jdrosen@dynamicsoft.com; 
> seancolson@yahoo.com
> > Cc: sip@ietf.org
> > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> > changes)
> > 
> > 
> > Hi,
> > 
> > If #2 is in any way possible, let's pursue that. Reading the 
> > bis-09 again, I can't help but wonder if the RFC2543 option of 
> > still trying with UDP, if TCP has failed actually provides value 
> > for messages over the UDP maximum datagram size of 65,535 bytes.
> > 
> > If there was a SHOULD in trying UDP when TCP fails, but a SHOULD 
> > NOT if size is over 65k, would the MESSAGE then be more well 
> > behaved? I.e., enough to be able to relax the size limit to a 
> > SHOULD strength in the message draft?
> > 
> > Otherwise, I'm ready to live with #2, given that the text is 
> > changed to align with bis-09 (MESSAGE talks about payload size, 
> > whereas bis-09 talks about request size), and provide with a way 
> > to send larger messages if there is a transport with congestion 
> > control all the way to the destination.
> > 
> > Cheers,
> > Aki
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> > > Sent: Saturday, May 18, 2002 12:17 AM
> > > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan
> > > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo)
> > > Cc: sip@ietf.org
> > > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] 
> Message draft
> > > changes)
> > > 
> > > 
> > > OK, to summarize where I think we are, I have seen 4 
> > > proposals for dealing
> > > with the message size controversy:
> > > 
> > > 1) Just live with it. IM's are not designed to carry large 
> > > content anyway.
> > > Large content should be sent using some other mechanism, like 
> > > in-session
> > > messages, content indirection, or something completely 
> > > different like email.
> > > (bottom line: limit stays, with perhaps a clarification of 
> > > the how the limit
> > > relates to the lowest hop MTU.)
> > > 
> > > 2) Fix the SIP "feature" that creates this problem in the 
> > > first place, i.e.
> > > the fact that a proxy can fail over to UDP even when a 
> > > congestion controlled
> > > transport is requested. Jonathan suggested dissallowing this 
> > > proxy behavior
> > > for large content messages. I'm not sure how hard that charge 
> > > would be to
> > > get into 3261.
> > > 
> > > 3) Adding something like a proxy-require:contestion-safe tag, 
> > > so that the
> > > UAC can insist on end-to-end congestion control. This of 
> > > course means that
> > > large content MESSAGE requests could not pass _any_ existing 
> > > proxies--but
> > > that is no more limiting than saying you can't have large 
> > > content messages
> > > at all. It at least gives us a way to relax the limit if we 
> > > someday do get
> > > proxies that support the tag.
> > > 
> > > 4) Relax the limit back to a should, but take no further 
> > > action. I do not
> > > think that would pass IESG muster at this point.
> > > 
> > > Personally I lean towards option 1. Pager model IMs are 
> really _not_
> > > intended to be a file transfer mechanism. Even without a 
> > > strict limit, I
> > > think that large content messages (where content is 
> > > physically carried in
> > > the message) are a misuse of the mechanism. We should work to 
> > > specify an
> > > indirect-content mechanism, a session based mechanism, or 
> > > both. But those
> > > are out of scope for pager model messaging, and should 
> not become a
> > > dependency for this draft. Option 4 is pretty much out of the 
> > > question. 2 &
> > > 3 may be doable, but are significant enough that we might 
> > > need to re-cycle
> > > the last call.
> > > 
> > > This really seems to be a full circle discussion, back to 
> > > IMPP requirements
> > > days. I think our best bet is to narrow the scope to something
> > > solveable--that is short text (or otherwise small content) 
> > > instant messages,
> > > solve that, then work on more sophisticated mechanisms for 
> > > large content.
> > > 
> > > Thoughts?
> > > 
> > > > -----Original Message-----
> > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > > Sent: Friday, May 17, 2002 2:51 PM
> > > > To: Michael Thomas
> > > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 
> 'Ben Campbell';
> > > > aki.niemi@nokia.com; sip@ietf.org
> > > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] 
> Message draft
> > > > changes)
> > > >
> > > >
> > > > Joking aside, this may not be such a bad idea: Send an IM 
> > > with a message
> > > > reference, with email sent simultaneously. Generally, mail 
> > > delivery is
> > > > measured in seconds (and for the long messages we're 
> > > talking about here,
> > > > any processing delays would tend to be overwhelmed by 
> > > transport delays).
> > > > Avoids all firewall, cable modem restriction and NAT 
> issues and, to
> > > > boot, leverages off the likelihood that SIP and SMTP 
> address are the
> > > > same. Plus, with IMAP, the client already gets to 
> decide whether to
> > > > download attachments or not.
> > > >
> > > > Michael Thomas wrote:
> > > > > Dean Willis writes:
> > > > >  >
> > > > >  > One must ask -- at what point should one 
> transition from IM to
> > > > >  > email?
> > > > >
> > > > >    Immediately?
> > > 
> > > 
> 

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



From daemon@optimus.ietf.org  Mon May 20 11:37:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08160
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 11:37:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14028
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 11:38:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11643;
	Mon, 20 May 2002 11:10:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11609
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 11:10:47 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06308
	for <sip@ietf.org>; Mon, 20 May 2002 11:10:27 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4KFB5k15798
	for <sip@ietf.org>; Mon, 20 May 2002 18:11:06 +0300 (EET DST)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5afb7baea8ac158f24077@esvir04nok.ntc.nokia.com>;
 Mon, 20 May 2002 18:10:43 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Mon, 20 May 2002 18:10:43 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Mon, 20 May 2002 18:10:41 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9010FE253@esebe013.NOE.Nokia.com>
Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Thread-Index: AcH96D4X/9oors2jSqyKRzzY7RPyWgB8oXFgAA1gDRA=
To: <aki.niemi@nokia.com>, <bcampbell@dynamicsoft.com>, <hgs@cs.columbia.edu>,
        <mat@cisco.com>, <dean.willis@softarmor.com>,
        <jdrosen@dynamicsoft.com>, <seancolson@yahoo.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 20 May 2002 15:10:43.0482 (UTC) FILETIME=[82DD67A0:01C20010]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA11610
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

> If #2 is in any way possible, let's pursue that. Reading the 
> bis-09 again, I can't help but wonder if the RFC2543 option 
> of still trying with UDP, if TCP has failed actually provides 
> value for messages over the UDP maximum datagram size of 65,535 bytes.
> 
> If there was a SHOULD in trying UDP when TCP fails, but a 
> SHOULD NOT if size is over 65k, would the MESSAGE then be 
> more well behaved? I.e., enough to be able to relax the size 
> limit to a SHOULD strength in the message draft?
> 
> Otherwise, I'm ready to live with #2, given that the text is 
                                    ^^

Here, I meant to say of course that #1 is all right by me. Sorry for the mixup ;)

> changed to align with bis-09 (MESSAGE talks about payload 
> size, whereas bis-09 talks about request size), and provide 
> with a way to send larger messages if there is a transport 
> with congestion control all the way to the destination.
> 
> Cheers,
> Aki
> 
>  
> 
> > -----Original Message-----
> > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> > Sent: Saturday, May 18, 2002 12:17 AM
> > To: Henning Schulzrinne; Michael Thomas; Dean Willis; 'Jonathan
> > Rosenberg'; 'Sean Olson'; Niemi Aki (NET/Espoo)
> > Cc: sip@ietf.org
> > Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft
> > changes)
> > 
> > 
> > OK, to summarize where I think we are, I have seen 4 
> > proposals for dealing
> > with the message size controversy:
> > 
> > 1) Just live with it. IM's are not designed to carry large 
> > content anyway.
> > Large content should be sent using some other mechanism, like 
> > in-session
> > messages, content indirection, or something completely 
> > different like email.
> > (bottom line: limit stays, with perhaps a clarification of 
> > the how the limit
> > relates to the lowest hop MTU.)
> > 
> > 2) Fix the SIP "feature" that creates this problem in the 
> > first place, i.e.
> > the fact that a proxy can fail over to UDP even when a 
> > congestion controlled
> > transport is requested. Jonathan suggested dissallowing this 
> > proxy behavior
> > for large content messages. I'm not sure how hard that charge 
> > would be to
> > get into 3261.
> > 
> > 3) Adding something like a proxy-require:contestion-safe tag, 
> > so that the
> > UAC can insist on end-to-end congestion control. This of 
> > course means that
> > large content MESSAGE requests could not pass _any_ existing 
> > proxies--but
> > that is no more limiting than saying you can't have large 
> > content messages
> > at all. It at least gives us a way to relax the limit if we 
> > someday do get
> > proxies that support the tag.
> > 
> > 4) Relax the limit back to a should, but take no further 
> > action. I do not
> > think that would pass IESG muster at this point.
> > 
> > Personally I lean towards option 1. Pager model IMs are really _not_
> > intended to be a file transfer mechanism. Even without a 
> > strict limit, I
> > think that large content messages (where content is 
> > physically carried in
> > the message) are a misuse of the mechanism. We should work to 
> > specify an
> > indirect-content mechanism, a session based mechanism, or 
> > both. But those
> > are out of scope for pager model messaging, and should not become a
> > dependency for this draft. Option 4 is pretty much out of the 
> > question. 2 &
> > 3 may be doable, but are significant enough that we might 
> > need to re-cycle
> > the last call.
> > 
> > This really seems to be a full circle discussion, back to 
> > IMPP requirements
> > days. I think our best bet is to narrow the scope to something
> > solveable--that is short text (or otherwise small content) 
> > instant messages,
> > solve that, then work on more sophisticated mechanisms for 
> > large content.
> > 
> > Thoughts?
> > 
> > > -----Original Message-----
> > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > > Sent: Friday, May 17, 2002 2:51 PM
> > > To: Michael Thomas
> > > Cc: Dean Willis; 'Jonathan Rosenberg'; 'Sean Olson'; 'Ben 
> Campbell';
> > > aki.niemi@nokia.com; sip@ietf.org
> > > Subject: Re: MESSAGE size limitations (Was: RE: [Sip] 
> Message draft
> > > changes)
> > >
> > >
> > > Joking aside, this may not be such a bad idea: Send an IM 
> > with a message
> > > reference, with email sent simultaneously. Generally, mail 
> > delivery is
> > > measured in seconds (and for the long messages we're 
> > talking about here,
> > > any processing delays would tend to be overwhelmed by 
> > transport delays).
> > > Avoids all firewall, cable modem restriction and NAT 
> issues and, to
> > > boot, leverages off the likelihood that SIP and SMTP 
> address are the
> > > same. Plus, with IMAP, the client already gets to decide 
> whether to
> > > download attachments or not.
> > >
> > > Michael Thomas wrote:
> > > > Dean Willis writes:
> > > >  >
> > > >  > One must ask -- at what point should one transition 
> from IM to
> > > >  > email?
> > > >
> > > >    Immediately?
> > 
> > 
> 

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



From daemon@optimus.ietf.org  Mon May 20 11:48:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08871
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 11:48:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14765
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 11:48:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13452;
	Mon, 20 May 2002 11:32:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA13321
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 11:32:19 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07703
	for <sip@ietf.org>; Mon, 20 May 2002 11:32:00 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4KFVUd06528;
	Mon, 20 May 2002 10:31:31 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>
Cc: <sip@ietf.org>, <sip@ietf.org>
Subject: RE: [Sip] Asserted-Identity: A P- Header?
Date: Mon, 20 May 2002 10:31:27 -0500
Message-ID: <000001c20013$69491110$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <200205191517.AAE25164@imop.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of Rohan Mahy
> Sent: Sunday, May 19, 2002 10:21 AM
> To: Peterson, Jon; Peterson, Jon
> Cc: sip@ietf.org; sip@ietf.org
> Subject: Re: [Sip] Asserted-Identity: A P- Header?
> 
> 
> Hi,
> 
> I believe a P- header is consistent with the applicability 
> scope built into the draft.
> 
> I also feel that the cryptographic identity draft should use 
> the Asserted-Identity header (without the P- ).
> 

I tend to disagree. It would appear that privacy requirements indicate
that removal of the P-Hint header would be required by a proxy in the
domain of trust before forwarding something out. This probably indicates
a requirement for a Proxy-Require so that UA's "know" that this
protection is provided by the proxy network. We can't do Proxy-Requires
for a P-header as far as I know.

--
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 daemon@optimus.ietf.org  Mon May 20 13:21:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20598
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 13:21:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA22170
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 13:21:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20334;
	Mon, 20 May 2002 12:59:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20298
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 12:59:48 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18283;
	Mon, 20 May 2002 12:59:31 -0400 (EDT)
Message-Id: <200205201659.MAA18283@ietf.org>
To: IETF-Announce: ;
Cc: sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Mon, 20 May 2002 12:59:30 -0400
Subject: [Sip] Last Call: The Refer Method to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol
Working Group to consider publication of the following Internet-Drafts
as Proposed Standards:

 o The Refer Method
	<draft-ietf-sip-refer-04.txt>
 o The Session Inititation Protocol (SIP)
	<draft-ietf-sip-replaces-02.txt>
 o The Reason Header Field for the Session Initiation Protocol
	<draft-ietf-sip-reason-01.txt>
 o Internet Media Types message/sipfrag
	<draft-sparks-sip-mimetypes-03.txt> 
 o SIP Extension for Registering Non-Adjacent Contacts
	<draft-willis-sip-path-06.txt>


The IESG will also consider publication of Best Current Practices for
Third Party Call Control in the Session Initiation Protocol
<draft-ietf-sipping-3pcc-00.txt> as a BCP.


The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002.

Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt
http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt
http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt


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



From daemon@optimus.ietf.org  Mon May 20 16:48:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09760
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 16:48:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA11177
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 16:48:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10264;
	Mon, 20 May 2002 16:35:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09267
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 16:28:16 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08140;
	Mon, 20 May 2002 16:27:57 -0400 (EDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1])
        by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g4KKSFl19468;
        Mon, 20 May 2002 16:28:15 -0400 (EDT)
Message-Id: <200205202028.g4KKSFl19468@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: iesg@ietf.org
cc: sip@ietf.org
In-reply-to: (Your message of "Mon, 20 May 2002 12:59:30 EDT.") 
             <200205201659.MAA18283@ietf.org> 
Date: Mon, 20 May 2002 16:28:15 -0400
Subject: [Sip] Re: Last Call: The Refer Method to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

> The IESG has received a request from the Session Initiation Protocol
> Working Group to consider publication of the following Internet-Drafts
> as Proposed Standards:
> 
>  o The Refer Method
>         <draft-ietf-sip-refer-04.txt>
> 

could you change the title to something like 
"The SIP Refer Method"?   it's getting harder and harder to 
tell what an RFC is about from looking at the title.


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



From daemon@optimus.ietf.org  Mon May 20 16:50:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09906
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 16:50:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA11328
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 16:50:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10542;
	Mon, 20 May 2002 16:38:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10502
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 16:38:39 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08995
	for <sip@ietf.org>; Mon, 20 May 2002 16:38:20 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4KKbad08458;
	Mon, 20 May 2002 15:37:36 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        <bernhard.honeisen@nokia.com>
Date: Mon, 20 May 2002 15:37:32 -0500
Message-ID: <005501c2003e$2b9f7cc0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I'd like to wrap up:

http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-04.txt


I think this version accomodates all changes requested to date.

Anybody still have anything to add? Speak now . . .

Thanks,

--
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 daemon@optimus.ietf.org  Mon May 20 17:16:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12044
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 17:16:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA14314
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 17:16:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11744;
	Mon, 20 May 2002 16:56:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11711
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 16:56:50 -0400 (EDT)
Received: from host.serversanddomains.com (host.serversanddomains.com [209.239.59.212])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10381
	for <sip@ietf.org>; Mon, 20 May 2002 16:56:30 -0400 (EDT)
Received: from victorpc ([206.184.140.167])
	by host.serversanddomains.com (8.10.2/8.10.2) with SMTP id g4KKukE10462;
	Mon, 20 May 2002 16:56:46 -0400
From: "Victor Paulsamy" <victor@zapex.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Date: Mon, 20 May 2002 13:55:10 -0700
Message-ID: <NEBBIPNANPGLCDPGFJGPKEJPCEAA.victor@zapex.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3CE6B3C1.91A3507@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] RE: Was the Translate heade used?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> Victor Paulsamy wrote:
> >
> > In "draft-rosenberg-sipping-nat-scenarios-00," page 27, paragraph last
> > but
> > one reads, "... From this 200 OK, the STUN agent knows whether or not
> > the
> > Translate header was used or not."
> >
> > In the example shown, the STUN agent learnt the public IP by querying
> > STUN
> > sever and changed the outgoing REGISTER appropriately to reflect this.
> > When
> > this request reaches the proxy, it checks the sent-by value against the
> > received address; they are same in this case (hence no received= param).
>
> No, they wouldn't be the same. The registration is sent over TCP, and
> uses a different port than was used to communicate with the STUN server.
>
The example message corresponding to the text is:

   REGISTER sip:provider.com SIP/2.0
   Via: SIP/2.0/UDP 1.2.3.4:5678
   From: sip:user@provider.com
   To: sip:user@provider.com
   Call-ID: 88sdasdlasd0
   Contact: sip:user@1.2.3.4:5678
   Translate: sip:user@1.2.3.4:5678
   CSeq: 88790 REGISTER

Here, the request is indeed, sent using UDP.

> > Say, the proxy supports SIP extensions for NAT. The proxy then rewrites
> > the
> > Translate header with sent-by value (in this case) which is same as the
> > original value it carried in it. When returned in the 200 OK response,
> > the
> > STUN agent sees that, the Translate header has the same value that it
> > put
> > in, yet, the proxy supports the extension for NAT.
>
> Since the source port is different than the Contact port, the contact
> would be rewritten and the client would know.
>
The source port (10) has been natted to 5678 (hence the port in Contact
holds 5678). The original request sent by the client:

   REGISTER sip:provider.com SIP/2.0
   Via: SIP/2.0/UDP 10.0.1.1
   From: sip:user@provider.com
   To: sip:user@provider.com
   Call-ID: 99asdasd98hnn
   Contact: sip:user@10.0.1.1:5060
   CSeq: 88790 REGISTER

The STUN agent finds out the address and port (as seen by the proxy) by
querying the STUN server; rewrites the message to:

   REGISTER sip:provider.com SIP/2.0
   Via: SIP/2.0/UDP 1.2.3.4:5678
   From: sip:user@provider.com
   To: sip:user@provider.com
   Call-ID: 88sdasdlasd0
   Contact: sip:user@1.2.3.4:5678
   Translate: sip:user@1.2.3.4:5678
   CSeq: 88790 REGISTER

When sent out, the NAT rewrites the source address and port (to
1.2.3.4:5678), finally reached the proxy. At the proxy, it sees a Translate
header hence, finds out a matching Contact header. The host value is
replaced with the sent-by field from the Via (which in this case, is same as
the value that's already present). The port number is replaced with the
sent-by field (again, the same value that's carried in it). Though, the
entire Contact header is rewritten, it results in the very same value it has
already been carrying!


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



From daemon@optimus.ietf.org  Mon May 20 17:22:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12560
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 17:22:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA14686
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 17:23:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13189;
	Mon, 20 May 2002 17:03:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13120
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 17:03:00 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10951;
	Mon, 20 May 2002 17:02:40 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4KL2Pd08622;
	Mon, 20 May 2002 16:02:25 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>, <sipping@ietf.org>
Date: Mon, 20 May 2002 16:02:22 -0500
Message-ID: <007201c20041$a2e472b0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Final notes, slides, etc. from MaySIP/SIPPING  interim meeting
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I think I've posted all the notes and slides I received related to the
interim meeting at:

http://www.softarmor.com/sipwg/meets/interim-may-02/index.html

Please let me know if we're still missing anything.

Thanks,

--
Your Humble Clerk-Typist
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 daemon@optimus.ietf.org  Mon May 20 20:52:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25482
	for <sip-archive@odin.ietf.org>; Mon, 20 May 2002 20:52:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA00704
	for sip-archive@odin.ietf.org; Mon, 20 May 2002 20:52:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28848;
	Mon, 20 May 2002 20:18:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28800
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 20:18:15 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23868
	for <sip@ietf.org>; Mon, 20 May 2002 20:17:57 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4L0Hgd09820;
	Mon, 20 May 2002 19:17:42 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: "'Keith Moore'" <moore@cs.utk.edu>
Subject: RE: [Sip] Re: Last Call: The Refer Method to Proposed Standard
Date: Mon, 20 May 2002 19:17:39 -0500
Message-ID: <009e01c2005c$eab532d0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <200205202028.g4KKSFl19468@astro.cs.utk.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Keith asked:
> could you change the title to something like 
> "The SIP Refer Method"?   it's getting harder and harder to 
> tell what an RFC is about from looking at the title.

This is a good suggestion. I've been trying to name things very
explicitly, like:

 SIP Extension Header Field for Service Route Discovery in Private
Networks

And:

 SIP Extension for Registering Non-Adjacent Contacts

which probably should have been: 

  SIP Extension Header Field for Registering Non-Adjacent Contacts

Perhaps we should put something on naming extension specs into the
"Guidelines for Authors of SIP Extensions" document?


--
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 daemon@optimus.ietf.org  Tue May 21 03:37:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24799
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 03:37:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA28981
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:37:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27809;
	Tue, 21 May 2002 03:16:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA27785
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 03:16:45 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23774
	for <sip@ietf.org>; Tue, 21 May 2002 03:16:28 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7HdYH017243;
	Tue, 21 May 2002 03:17:39 -0400 (EDT)
Message-ID: <3CE9F436.A2ED116C@dynamicsoft.com>
Date: Tue, 21 May 2002 03:16:06 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org, "'Keith Moore'" <moore@cs.utk.edu>
Subject: Re: [Sip] Re: Last Call: The Refer Method to Proposed Standard
References: <009e01c2005c$eab532d0$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I'll add some words to the authors guidelines draft about this.

Thanks,
Jonathan R.

Dean Willis wrote:
> 
> Keith asked:
> > could you change the title to something like
> > "The SIP Refer Method"?   it's getting harder and harder to
> > tell what an RFC is about from looking at the title.
> 
> This is a good suggestion. I've been trying to name things very
> explicitly, like:
> 
>  SIP Extension Header Field for Service Route Discovery in Private
> Networks
> 
> And:
> 
>  SIP Extension for Registering Non-Adjacent Contacts
> 
> which probably should have been:
> 
>   SIP Extension Header Field for Registering Non-Adjacent Contacts
> 
> Perhaps we should put something on naming extension specs into the
> "Guidelines for Authors of SIP Extensions" document?
> 
> --
> 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

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

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



From daemon@optimus.ietf.org  Tue May 21 03:47:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25415
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 03:47:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA29531
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:47:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28147;
	Tue, 21 May 2002 03:29:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28116
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 03:29:26 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24398
	for <sip@ietf.org>; Tue, 21 May 2002 03:29:09 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7TrYH017259;
	Tue, 21 May 2002 03:29:53 -0400 (EDT)
Message-ID: <3CE9F714.59EC6FEF@dynamicsoft.com>
Date: Tue, 21 May 2002 03:28:20 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: bcampbell@dynamicsoft.com, hgs@cs.columbia.edu, mat@cisco.com,
        dean.willis@softarmor.com, seancolson@yahoo.com, sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED11@esebe013.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



aki.niemi@nokia.com wrote:
> 
> Hi,
> 
> If #2 is in any way possible, let's pursue that. Reading the bis-09
> again, I can't help but wonder if the RFC2543 option of still trying
> with UDP, if TCP has failed actually provides value for messages over
> the UDP maximum datagram size of 65,535 bytes.

Well, to be honest, there are other reasons why sending such large
content (over 64k) in SIP directly is a bad idea in any case, TCP or no
TCP. I can't tell you how many times I've flamed people for sending 10M
email attachments to mailing lists; I always prefer a URL so that I can
fetch it at my convenience. 

MMS in the GSM world works the same; everything is via indirection.

My concern is actually with the arbitraryness of the 1300 number; I fear
there will be cases when an indirection might even exceed this limit (in
the case of S/MIME with a cert chain). Last thing we want to do is
discourage S/MIME usage...

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Tue May 21 03:48:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25483
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 03:48:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA29552
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:48:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28741;
	Tue, 21 May 2002 03:33:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28710
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 03:33:56 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24607
	for <sip@ietf.org>; Tue, 21 May 2002 03:33:38 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7YoYH017262;
	Tue, 21 May 2002 03:34:50 -0400 (EDT)
Message-ID: <3CE9F83E.FA53CE9F@dynamicsoft.com>
Date: Tue, 21 May 2002 03:33:18 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
CC: Sean Olson <seancolson@yahoo.com>,
        Ben Campbell <bcampbell@dynamicsoft.com>, aki.niemi@nokia.com,
        sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
References: <15589.10039.127865.917811@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Michael Thomas wrote:
> 
> Jonathan Rosenberg writes:
>  >
>  >
>  > Sean Olson wrote:
>  > >
>  > > The consent piece is an interesting adjunct to the
>  > > content indirection requirements. I already allude
>  > > to the fact that you need to be able to negotiate
>  > > support / demand for such a mechanism.
>  > >
>  > > Do we need to express explicit policy about when
>  > > content indirection should be used?
>  >
>  > What I was saying is that the page mode spec DEFINES that policy
>  > explicitly - anything over 1300 bytes means indirection.
> 
> Jonathan,
> 
> While I like the spirit of your proposal, I wonder
> if it's going to run into operational problems.
> Client's don't typically run web servers
> (especially on some well known OSen). Also: some
> cable MSO's filter port 80 to kill home web
> servers. That means that they'd have to find and
> upload that data to a willing web server. For
> long-lived data that's not unreasonable, but for
> short term/transient data that seems like a pretty
> big burden.

Well, in the wireless world, there is an argument to be made
that almost all large data won't be stored on the phone in any case,
but rather available on a server. Clearly there are exceptions (those
new phones with built in cameras, i.e., the Danger device), and
clearly this isn't true for PCs on the wired Internet.

However, if we had a procedure that allowed an automata on the phone to
upload content
to a server, specify a lifetime, and set permissions on who can fetch
the
content, I see no drawbacks to the approach of uploading it to such a
server.
These kinds of servers are already features of existing wired IM
solutions,
which use them mostly for file transfer right now. 

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

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



From daemon@optimus.ietf.org  Tue May 21 03:58:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26021
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 03:58:54 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA29860
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 03:59:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28862;
	Tue, 21 May 2002 03:36:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA28831
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 03:36:10 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24707
	for <sip@ietf.org>; Tue, 21 May 2002 03:35:53 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.84])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4L7b6YH017265;
	Tue, 21 May 2002 03:37:07 -0400 (EDT)
Message-ID: <3CE9F8C6.68147C6C@dynamicsoft.com>
Date: Tue, 21 May 2002 03:35:34 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org
Subject: Re: [Sip] Message draft changes
References: <HNEOJECGFHIABDLENMMCMENPCIAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> 

> > Careful here! Path and hop mean different things to folks at layer 3
> and
> > at the app layer. The Path MTU refers to the smallest MTU along each
> > router hop from the IP source to the IP destination. For SIP, that is
> > just a single "hop" from the UAC to a proxy, say. Each SIP "hop"
> > (between UAC and proxy, or proxy to proxy) will have a different path
> > MTU, and could conceivably make a different transport decision based
> on
> > that.
> 
> Ah, thanks for the terminology lession--I mean to say, that it is very
> unlikely that the MTU will know the smallest path MTU for every SIP
> device
> end-to-end.

Actually, I think you mean to say that it is very unlikely that the UA
will know the path MTU for reaching every sip device. I agree, but its
not the case that it needs to know. In most usages, the UA will talk to
an outbound proxy, and it will know the path MTU to the outbound proxy.
Its determination about whether to use UDP or TCP would then be based on
this specific path MTU.

-Jonathan R.


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

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



From daemon@optimus.ietf.org  Tue May 21 04:31:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27759
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 04:31:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA02576
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 04:31:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01305;
	Tue, 21 May 2002 04:15:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA01278
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 04:15:46 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26999
	for <sip@ietf.org>; Tue, 21 May 2002 04:15:27 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4L8G5k03537
	for <sip@ietf.org>; Tue, 21 May 2002 11:16:05 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5aff26100eac158f24077@esvir04nok.ntc.nokia.com>;
 Tue, 21 May 2002 11:15:41 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 21 May 2002 11:15:41 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Tue, 21 May 2002 11:15:40 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED1F@esebe013.NOE.Nokia.com>
Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Thread-Index: AcIAmSq6HfW4N/E9RYSf0tO7101DowABLWNw
To: <jdrosen@dynamicsoft.com>
Cc: <bcampbell@dynamicsoft.com>, <hgs@cs.columbia.edu>, <mat@cisco.com>,
        <dean.willis@softarmor.com>, <seancolson@yahoo.com>, <sip@ietf.org>
X-OriginalArrivalTime: 21 May 2002 08:15:41.0089 (UTC) FILETIME=[B24B8910:01C2009F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA01279
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

> > If #2 is in any way possible, let's pursue that. Reading the bis-09
> > again, I can't help but wonder if the RFC2543 option of still trying
> > with UDP, if TCP has failed actually provides value for 
> messages over
> > the UDP maximum datagram size of 65,535 bytes.
> 
> Well, to be honest, there are other reasons why sending such large
> content (over 64k) in SIP directly is a bad idea in any case, 
> TCP or no
> TCP. I can't tell you how many times I've flamed people for 
> sending 10M
> email attachments to mailing lists; I always prefer a URL so 
> that I can
> fetch it at my convenience. 

I totally agree. However, I know of email lists / systems, which have local policy governing the sizes of attachments. I feel such optionality is currently missing from the MESSAGE draft. For example, the default content-indirection policy seems to be that the sender always performs it. How about if this was part of the recipient's service offering? Sort of like a safeguard for UAs behind the low-capacity links.
 
> MMS in the GSM world works the same; everything is via indirection.

But only on the "last hop", i.e., the core MMS infra still has direct content all the way. I actually think this model should be available for the SIP MESSAGE indirection as well.
 
> My concern is actually with the arbitraryness of the 1300 
> number; I fear
> there will be cases when an indirection might even exceed 
> this limit (in
> the case of S/MIME with a cert chain). Last thing we want to do is
> discourage S/MIME usage...

Yes, and in fact concerning this, there is an inconsistency with the SIP spec, which talks about 1300 bytes for the *whole* request. If we abide by that limit, with those lengthy Subject fields etc., there is even less space for the indirection object in the payload.

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 daemon@optimus.ietf.org  Tue May 21 04:42:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28289
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 04:42:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA02851
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 04:42:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02092;
	Tue, 21 May 2002 04:28:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA02061
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 04:28:48 -0400 (EDT)
Received: from webmail22.rediffmail.com (webmail22.rediffmail.com [203.199.83.32] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27608
	for <sip@ietf.org>; Tue, 21 May 2002 04:28:28 -0400 (EDT)
Received: (qmail 393 invoked by uid 510); 21 May 2002 08:27:26 -0000
Date: 21 May 2002 08:27:26 -0000
Message-ID: <20020521082726.392.qmail@webmail22.rediffmail.com>
Received: from unknown (203.197.251.7) by rediffmail.com via HTTP; 21 May 2002 08:27:26 -0000
MIME-Version: 1.0
From: "Ashhar Farhan" <afarhan@rediffmail.com>
Reply-To: "Ashhar Farhan" <afarhan@rediffmail.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: bcampbell@dynamicsoft.com, hgs@cs.columbia.edu, mat@cisco.com,
        dean.willis@softarmor.com, seancolson@yahoo.com, sip@ietf.org,
        aki.niemi@nokia.com
Subject: Re: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

if the messages are no longer just text, then there is a case for 
negotiating content-type. the UA may or may not be able to display 
html for instance and might want a short text description instead. 
in which case:
(1) do we have to return 'Method Not supported' in the response?
(2) do we also recommend an alternative?
- farhan
_________________________________________________________
Click below to visit monsterindia.com and review jobs in India or 
Abroad
http://monsterindia.rediff.com/jobs


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



From daemon@optimus.ietf.org  Tue May 21 06:30:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02823
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 06:30:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA08772
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 06:30:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07704;
	Tue, 21 May 2002 06:02:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA07677
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 06:02:11 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01711
	for <sip@ietf.org>; Tue, 21 May 2002 06:01:51 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4LA27s7008882;
	Tue, 21 May 2002 12:02:07 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4LA279q010580;
	Tue, 21 May 2002 13:02:07 +0300 (EET DST)
Message-ID: <3CEA1B1E.E4E20C18@lmf.ericsson.se>
Date: Tue, 21 May 2002 13:02:06 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip <sip@ietf.org>
CC: Allison Mankin <mankin@isi.edu>,
        "Jari Arkko (LMF)" <Jari.Arkko@lmf.ericsson.se>,
        "Vesa Torvinen (LMF)" <Vesa.Torvinen@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Reviewers for the sec-agree draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello folks,

we need SIP people willing to have a look at the new version (01) of the
sec-agree draft (released one week and a half ago).

http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-sec-agree-01.txt

As you proabbly know, the previous version (00) had some problems that
were discovered during the iterim meeting in Vegas. The discovery of
problems (such as a broken SIP syntax) at that point of time (after the
WGLC had finished) indicates that nobody in the SIP WG bothered to read
the document.

I am not saying that this draft is so interesting that everyone will
enjoy reading it, but we would need at least a couple of reviewers that
are familiar with SIP and have the energy to review the document. We
cannot let the SIP WG send documents to the IESG that have major flaws!


Here you have a brief summary of the changes we introduced to the new
version of the draft (01):

The syntax has been fixed. Now it is allowed to have different security
mechanisms listed (separated by commas or in different lines). The
previous draft used commas to separate security mechanism tokens. That
made the header field non-SIP compliant.

The scope has been narrowed down. Before, the draft tried to solve every
security negotiation problem that could be found in a SIP network. Now
the draft only tries to resolve the security negotiation between a host
and its next SIP hop (e.g., UA and the outbound proxy).


The negotiation works as follows. The UA sends a SIP message (typically
OPTIONS) to its outbound proxy listing its security capabilities (e.g.,
TLS and IPSec). The outbound proxy sends a response with its own
capabilities (it is important that the list in the server is static).
With this information, client and server initiate the security mechanims
(e.g., initiate a TLS conection).

When the client sends another SIP message to the outbound proxy, this
time using the TLS connection, it includes a header field that contains
the list obtained previously from the server. This way, the server can
check whether a MitM changes the list in order to perform a bid-down
attack.

Of course, this security negotiation mechanism requires that all the
security mechanisms advertised provide integrity protection, at least.

Thank you,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@optimus.ietf.org  Tue May 21 07:55:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05810
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 07:55:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA13250
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 07:56:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12046;
	Tue, 21 May 2002 07:31:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12017
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 07:31:51 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05072;
	Tue, 21 May 2002 07:31:32 -0400 (EDT)
Message-Id: <200205211131.HAA05072@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 May 2002 07:31:31 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-digest-aka-03.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: HTTP Digest Authentication Using AKA
	Author(s)	: A. Niemi, J. Arkko, V. Torvinen
	Filename	: draft-ietf-sip-digest-aka-03.txt
	Pages		: 18
	Date		: 20-May-02
	
The Hypertext Transfer Protocol (HTTP) Authentication Framework
includes two authentication schemes: Basic and Digest.  Both schemes
employ a shared secret based mechanism for access authentication.
The Authentication and Key Agreement (AKA) mechanism performs user
authentication and session key distribution in Universal Mobile
Telecommunications System (UMTS) networks.  AKA is a challenge-
response based mechanism that uses symmetric cryptography.  This memo
specifies an AKA based one-time password generation mechanism for
HTTP Digest access authentication.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-digest-aka-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-digest-aka-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:	<20020520143415.I-D@ietf.org>

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Tue May 21 07:58:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05981
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 07:58:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA13299
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 07:58:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11861;
	Tue, 21 May 2002 07:31:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11819
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 07:31:11 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04885;
	Tue, 21 May 2002 07:30:47 -0400 (EDT)
Message-Id: <200205211130.HAA04885@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 May 2002 07:30:47 -0400
Subject: [Sip] I-D ACTION:draft-garcia-sip-associated-uri-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private Session Initiation Protocol extension for 
                          Associated Uniform Resource Identifiers
	Author(s)	: M. Garcia
	Filename	: draft-garcia-sip-associated-uri-01.txt
	Pages		: 6
	Date		: 20-May-02
	
This memo describes a private extension to SIP [1] that allows a
registrar to return a set of Associated URIs to a UAC. We define the
P-Associated-URI header, used in the 200 OK response to a REGISTER
request or 200-class response to a SUBSCRIBE. The P-Associated-URI
header transports the set of Associated URIs to the SIP URI that has
been registered or subscribed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-garcia-sip-associated-uri-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-garcia-sip-associated-uri-01.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-garcia-sip-associated-uri-01.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:	<20020520143242.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-garcia-sip-associated-uri-01.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Tue May 21 07:58:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05997
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 07:58:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA13313
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 07:58:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11908;
	Tue, 21 May 2002 07:31:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11856
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 07:31:15 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04901;
	Tue, 21 May 2002 07:30:52 -0400 (EDT)
Message-Id: <200205211130.HAA04901@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 May 2002 07:30:51 -0400
Subject: [Sip] I-D ACTION:draft-garcia-sip-visited-network-id-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private Session Initiation Protocol extension for 
                          Visited Network Identifier
	Author(s)	: M. Garcia
	Filename	: draft-garcia-sip-visited-network-id-01.txt
	Pages		: 7
	Date		: 20-May-02
	
This memo describes a private extension to SIP in the form of a
P-Visited-Network-ID header. The contents of the header identify each
of the visited networks the message traversed en-route to the home
network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-garcia-sip-visited-network-id-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-garcia-sip-visited-network-id-01.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-garcia-sip-visited-network-id-01.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:	<20020520143252.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-garcia-sip-visited-network-id-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-garcia-sip-visited-network-id-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Tue May 21 08:00:30 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06115
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 08:00:29 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA13686
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 08:00:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11797;
	Tue, 21 May 2002 07:31:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA11766
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 07:31:02 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04864;
	Tue, 21 May 2002 07:30:42 -0400 (EDT)
Message-Id: <200205211130.HAA04864@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Tue, 21 May 2002 07:30:42 -0400
Subject: [Sip] I-D ACTION:draft-garcia-sip-called-party-id-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private  Session Initiation Protocol extension for 
                          Called Party Identity
	Author(s)	: M. Garcia
	Filename	: draft-garcia-sip-called-party-id-01.txt
	Pages		: 8
	Date		: 20-May-02
	
This memo describes a private extension to SIP in the form of a
P-Called-Party-ID header. A proxy inserts this header typically in an
INVITE, en-route to its destination. The header is populated with the
Request-URI received by the proxy in the request. The UAS identifies
which ID out of several IDs the invitation was sent to (for example,
the user may be using simultaneously a personal and a business SIP URI
to receive invitation to sessions). The UAS may use the information to
render different distinctive audiovisual alerting tones, depending on
the ID used to receive the invitation to the session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-garcia-sip-called-party-id-01.txt

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-garcia-sip-called-party-id-01.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-garcia-sip-called-party-id-01.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:	<20020520143232.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-garcia-sip-called-party-id-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-garcia-sip-called-party-id-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Tue May 21 08:39:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07544
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 08:39:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA15427
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 08:39:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14277;
	Tue, 21 May 2002 08:14:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA14246
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 08:14:21 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06514
	for <sip@ietf.org>; Tue, 21 May 2002 08:14:03 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA03670;
	Tue, 21 May 2002 08:14:18 -0400 (EDT)
Received: from cs.columbia.edu (pool-138-89-39-64.mad.east.verizon.net [138.89.39.64])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4LCEF2i005157
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 21 May 2002 08:14:16 -0400 (EDT)
Message-ID: <3CEA3A4D.8070904@cs.columbia.edu>
Date: Tue, 21 May 2002 08:15:09 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org,
        "'Keith Moore'"
 <moore@cs.utk.edu>
Subject: Re: [Sip] Re: Last Call: The Refer Method to Proposed Standard
References: <009e01c2005c$eab532d0$1d036e3f@TXDWILLIS2> <3CE9F436.A2ED116C@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

We should probably be consistent. We're seeing a lot of drafts titled 
something like "Private Session Initiation Protocol feature to do foo", 
others "SIP extension to do bar". It would be nice to be able to easily 
grep the RFC list and come up with all SIP-related drafts.

Jonathan Rosenberg wrote:
> I'll add some words to the authors guidelines draft about this.
> 
> Thanks,
> Jonathan R.
> 
> Dean Willis wrote:
> 
>>Keith asked:
>>
>>>could you change the title to something like
>>>"The SIP Refer Method"?   it's getting harder and harder to
>>>tell what an RFC is about from looking at the title.
>>
>>This is a good suggestion. I've been trying to name things very
>>explicitly, like:
>>
>> SIP Extension Header Field for Service Route Discovery in Private
>>Networks
>>
>>And:
>>
>> SIP Extension for Registering Non-Adjacent Contacts
>>
>>which probably should have been:
>>
>>  SIP Extension Header Field for Registering Non-Adjacent Contacts
>>
>>Perhaps we should put something on naming extension specs into the
>>"Guidelines for Authors of SIP Extensions" document?
>>
>>--
>>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 daemon@optimus.ietf.org  Tue May 21 10:07:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11047
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 10:07:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA19884
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:07:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18513;
	Tue, 21 May 2002 09:40:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA18484
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 09:40:45 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10153
	for <sip@ietf.org>; Tue, 21 May 2002 09:40:26 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4LDYpX59091;
	Tue, 21 May 2002 08:34:51 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <hisham.khartabil@nokia.com>, <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: [Sip] Message draft changes
Date: Tue, 21 May 2002 08:34:37 -0500
Message-ID: <HNEOJECGFHIABDLENMMCGECACJAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <3CE9F8C6.68147C6C@dynamicsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]

[snip]

> Actually, I think you mean to say that it is very unlikely that the UA
> will know the path MTU for reaching every sip device. I agree, but its
> not the case that it needs to know. In most usages, the UA will talk to
> an outbound proxy, and it will know the path MTU to the outbound proxy.
> Its determination about whether to use UDP or TCP would then be based on
> this specific path MTU.
>

Yes, that is what I mean. Why does only the first hop matter for the UDP/TCP
decision?


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



From daemon@optimus.ietf.org  Tue May 21 10:27:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11813
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 10:27:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA20936
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:27:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19972;
	Tue, 21 May 2002 10:09:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19926
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 10:09:21 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11127
	for <sip@ietf.org>; Tue, 21 May 2002 10:09:01 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4LE3RX61346;
	Tue, 21 May 2002 09:03:27 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Ashhar Farhan" <afarhan@rediffmail.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <hgs@cs.columbia.edu>, <mat@cisco.com>, <dean.willis@softarmor.com>,
        <seancolson@yahoo.com>, <sip@ietf.org>, <aki.niemi@nokia.com>
Subject: RE: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Tue, 21 May 2002 09:03:13 -0500
Message-ID: <HNEOJECGFHIABDLENMMCOECCCJAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <20020521082726.392.qmail@webmail22.rediffmail.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> Sent: Tuesday, May 21, 2002 3:27 AM
> To: Jonathan Rosenberg
> Cc: bcampbell@dynamicsoft.com; hgs@cs.columbia.edu; mat@cisco.com;
> dean.willis@softarmor.com; seancolson@yahoo.com; sip@ietf.org;
> aki.niemi@nokia.com
> Subject: Re: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft
> changes)
>
>
> if the messages are no longer just text, then there is a case for
> negotiating content-type. the UA may or may not be able to display
> html for instance and might want a short text description instead.
> in which case:
> (1) do we have to return 'Method Not supported' in the response?
> (2) do we also recommend an alternative?
> - farhan

SIP already has a mechanism for dealing with this situation. Do you think
that MESSAGE requires more here?


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



From daemon@optimus.ietf.org  Tue May 21 10:28:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11876
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 10:28:35 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA20993
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:28:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19502;
	Tue, 21 May 2002 10:01:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19467
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 10:01:12 -0400 (EDT)
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10780
	for <sip@ietf.org>; Tue, 21 May 2002 10:00:53 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 May 2002 14:01:34 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] Reviewers for the sec-agree draft
Date: Tue, 21 May 2002 15:01:11 +0100
Message-ID: <45730E094814E44488F789C1CDED27AEC552F4@GBNEWP0758M.eu.ubiquity.net>
Thread-Topic: [Sip] Reviewers for the sec-agree draft
Thread-Index: AcIAsRCSYZA7u0SdQbm/8OSUMLuMrQAHedKQ
From: "James Undery" <jundery@ubiquity.net>
To: "Gonzalo Camarillo" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "sip" <sip@ietf.org>
Cc: "Jari Arkko (LMF)" <Jari.Arkko@lmf.ericsson.se>,
        "Vesa Torvinen (LMF)" <Vesa.Torvinen@lmf.ericsson.se>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA19468
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

I'll have to admit myself of being guilty of not reading drafts
recently. But I'd note digest-integrity needs to be dropped as it
protects the body of messages only. If it can't be dropped a lpidf like
extension would be required 
(http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt) to
place your headers in the body.

James

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 21 May 2002 11:02
> To: sip
> Cc: Allison Mankin; Jari Arkko (LMF); Vesa Torvinen (LMF)
> Subject: [Sip] Reviewers for the sec-agree draft
> 
> 
> Hello folks,
> 
> we need SIP people willing to have a look at the new version 
> (01) of the
> sec-agree draft (released one week and a half ago).
> 
> http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se
> c-agree-01.txt
> 
> As you proabbly know, the previous version (00) had some problems that
> were discovered during the iterim meeting in Vegas. The discovery of
> problems (such as a broken SIP syntax) at that point of time 
> (after the
> WGLC had finished) indicates that nobody in the SIP WG 
> bothered to read
> the document.
> 
> I am not saying that this draft is so interesting that everyone will
> enjoy reading it, but we would need at least a couple of 
> reviewers that
> are familiar with SIP and have the energy to review the document. We
> cannot let the SIP WG send documents to the IESG that have 
> major flaws!
> 
> 
> Here you have a brief summary of the changes we introduced to the new
> version of the draft (01):
> 
> The syntax has been fixed. Now it is allowed to have 
> different security
> mechanisms listed (separated by commas or in different lines). The
> previous draft used commas to separate security mechanism tokens. That
> made the header field non-SIP compliant.
> 
> The scope has been narrowed down. Before, the draft tried to 
> solve every
> security negotiation problem that could be found in a SIP network. Now
> the draft only tries to resolve the security negotiation 
> between a host
> and its next SIP hop (e.g., UA and the outbound proxy).
> 
> 
> The negotiation works as follows. The UA sends a SIP message 
> (typically
> OPTIONS) to its outbound proxy listing its security 
> capabilities (e.g.,
> TLS and IPSec). The outbound proxy sends a response with its own
> capabilities (it is important that the list in the server is static).
> With this information, client and server initiate the 
> security mechanims
> (e.g., initiate a TLS conection).
> 
> When the client sends another SIP message to the outbound proxy, this
> time using the TLS connection, it includes a header field 
> that contains
> the list obtained previously from the server. This way, the server can
> check whether a MitM changes the list in order to perform a bid-down
> attack.
> 
> Of course, this security negotiation mechanism requires that all the
> security mechanisms advertised provide integrity protection, at least.
> 
> Thank you,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May 21 10:44:21 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12584
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 10:44:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA22249
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:44:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20549;
	Tue, 21 May 2002 10:22:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20521
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 10:22:03 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11543
	for <sip@ietf.org>; Tue, 21 May 2002 10:21:44 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LELWa16441;
	Tue, 21 May 2002 09:21:33 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXXTNJ6>; Tue, 21 May 2002 09:21:35 -0500
Message-ID: <933FADF5E673D411B8A30002A5608A0E03A632A1@zrc2c012.us.nortel.com>
From: "Sanjoy Sen"<sanjoy@nortelnetworks.com>
To: "'James Undery'" <jundery@ubiquity.net>,
        "'Gonzalo Camarillo'"
	 <Gonzalo.Camarillo@lmf.ericsson.se>,
        "'sip'" <sip@ietf.org>
Cc: "'Jari Arkko (LMF)'" <Jari.Arkko@lmf.ericsson.se>,
        "'Vesa Torvinen (LMF)'" <Vesa.Torvinen@lmf.ericsson.se>
Subject: RE: [Sip] Reviewers for the sec-agree draft
Date: Tue, 21 May 2002 09:21:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C200D2.CAA6DAE0"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

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

James,

The use of 'sipfrag' (draft-sparks-sip-mimetypes-03 or whatever is the
latest version) is assumed. But, I agree that it should be explicitly stated
for clarity.

Sanjoy

> -----Original Message-----
> From: James Undery [mailto:jundery@ubiquity.net]
> Sent: Tuesday, May 21, 2002 9:01 AM
> To: Gonzalo Camarillo; sip
> Cc: Jari Arkko (LMF); Vesa Torvinen (LMF)
> Subject: RE: [Sip] Reviewers for the sec-agree draft
> 
> 
> Hi,
> 
> I'll have to admit myself of being guilty of not reading drafts
> recently. But I'd note digest-integrity needs to be dropped as it
> protects the body of messages only. If it can't be dropped a 
> lpidf like
> extension would be required 
> (http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt) to
> place your headers in the body.
> 
> James
> 
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> > Sent: 21 May 2002 11:02
> > To: sip
> > Cc: Allison Mankin; Jari Arkko (LMF); Vesa Torvinen (LMF)
> > Subject: [Sip] Reviewers for the sec-agree draft
> > 
> > 
> > Hello folks,
> > 
> > we need SIP people willing to have a look at the new version 
> > (01) of the
> > sec-agree draft (released one week and a half ago).
> > 
> > http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se
> > c-agree-01.txt
> > 
> > As you proabbly know, the previous version (00) had some 
> problems that
> > were discovered during the iterim meeting in Vegas. The discovery of
> > problems (such as a broken SIP syntax) at that point of time 
> > (after the
> > WGLC had finished) indicates that nobody in the SIP WG 
> > bothered to read
> > the document.
> > 
> > I am not saying that this draft is so interesting that everyone will
> > enjoy reading it, but we would need at least a couple of 
> > reviewers that
> > are familiar with SIP and have the energy to review the document. We
> > cannot let the SIP WG send documents to the IESG that have 
> > major flaws!
> > 
> > 
> > Here you have a brief summary of the changes we introduced 
> to the new
> > version of the draft (01):
> > 
> > The syntax has been fixed. Now it is allowed to have 
> > different security
> > mechanisms listed (separated by commas or in different lines). The
> > previous draft used commas to separate security mechanism 
> tokens. That
> > made the header field non-SIP compliant.
> > 
> > The scope has been narrowed down. Before, the draft tried to 
> > solve every
> > security negotiation problem that could be found in a SIP 
> network. Now
> > the draft only tries to resolve the security negotiation 
> > between a host
> > and its next SIP hop (e.g., UA and the outbound proxy).
> > 
> > 
> > The negotiation works as follows. The UA sends a SIP message 
> > (typically
> > OPTIONS) to its outbound proxy listing its security 
> > capabilities (e.g.,
> > TLS and IPSec). The outbound proxy sends a response with its own
> > capabilities (it is important that the list in the server 
> is static).
> > With this information, client and server initiate the 
> > security mechanims
> > (e.g., initiate a TLS conection).
> > 
> > When the client sends another SIP message to the outbound 
> proxy, this
> > time using the TLS connection, it includes a header field 
> > that contains
> > the list obtained previously from the server. This way, the 
> server can
> > check whether a MitM changes the list in order to perform a bid-down
> > attack.
> > 
> > Of course, this security negotiation mechanism requires that all the
> > security mechanisms advertised provide integrity 
> protection, at least.
> > 
> > Thank you,
> > 
> > Gonzalo
> > -- 
> > Gonzalo Camarillo         Phone :  +358  9 299 33 71
> > Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> > Telecom R&D               Fax   :  +358  9 299 30 52
> > FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> > Finland                   http://www.hut.fi/~gonzalo
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [Sip] Reviewers for the sec-agree draft</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>The use of 'sipfrag' (draft-sparks-sip-mimetypes-03 =
or whatever is the latest version) is assumed. But, I agree that it =
should be explicitly stated for clarity.</FONT></P>

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

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: James Undery [<A =
HREF=3D"mailto:jundery@ubiquity.net">mailto:jundery@ubiquity.net</A>]</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, May 21, 2002 9:01 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Gonzalo Camarillo; sip</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Jari Arkko (LMF); Vesa Torvinen =
(LMF)</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Sip] Reviewers for the sec-agree =
draft</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'll have to admit myself of being guilty of =
not reading drafts</FONT>
<BR><FONT SIZE=3D2>&gt; recently. But I'd note digest-integrity needs =
to be dropped as it</FONT>
<BR><FONT SIZE=3D2>&gt; protects the body of messages only. If it can't =
be dropped a </FONT>
<BR><FONT SIZE=3D2>&gt; lpidf like</FONT>
<BR><FONT SIZE=3D2>&gt; extension would be required </FONT>
<BR><FONT SIZE=3D2>&gt; (<A =
HREF=3D"http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt"=
 =
TARGET=3D"_blank">http://www.jdrosen.net/papers/draft-rosenberg-impp-lpi=
df-00.txt</A>) to</FONT>
<BR><FONT SIZE=3D2>&gt; place your headers in the body.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; James</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Gonzalo Camarillo [<A =
HREF=3D"mailto:Gonzalo.Camarillo@lmf.ericsson.se">mailto:Gonzalo.Camaril=
lo@lmf.ericsson.se</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 21 May 2002 11:02</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: Allison Mankin; Jari Arkko (LMF); Vesa =
Torvinen (LMF)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: [Sip] Reviewers for the sec-agree =
draft</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hello folks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; we need SIP people willing to have a look =
at the new version </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (01) of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; sec-agree draft (released one week and a =
half ago).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se" =
TARGET=3D"_blank">http://standards.ericsson.net/gonzalo/papers/draft-iet=
f-sip-se</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; c-agree-01.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; As you proabbly know, the previous version =
(00) had some </FONT>
<BR><FONT SIZE=3D2>&gt; problems that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; were discovered during the iterim meeting =
in Vegas. The discovery of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problems (such as a broken SIP syntax) at =
that point of time </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (after the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; WGLC had finished) indicates that nobody =
in the SIP WG </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; bothered to read</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I am not saying that this draft is so =
interesting that everyone will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; enjoy reading it, but we would need at =
least a couple of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reviewers that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are familiar with SIP and have the energy =
to review the document. We</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cannot let the SIP WG send documents to =
the IESG that have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; major flaws!</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Here you have a brief summary of the =
changes we introduced </FONT>
<BR><FONT SIZE=3D2>&gt; to the new</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; version of the draft (01):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The syntax has been fixed. Now it is =
allowed to have </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; different security</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mechanisms listed (separated by commas or =
in different lines). The</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; previous draft used commas to separate =
security mechanism </FONT>
<BR><FONT SIZE=3D2>&gt; tokens. That</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; made the header field non-SIP =
compliant.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The scope has been narrowed down. Before, =
the draft tried to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; solve every</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; security negotiation problem that could be =
found in a SIP </FONT>
<BR><FONT SIZE=3D2>&gt; network. Now</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the draft only tries to resolve the =
security negotiation </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; between a host</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and its next SIP hop (e.g., UA and the =
outbound proxy).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The negotiation works as follows. The UA =
sends a SIP message </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (typically</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OPTIONS) to its outbound proxy listing its =
security </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; capabilities (e.g.,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; TLS and IPSec). The outbound proxy sends a =
response with its own</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; capabilities (it is important that the =
list in the server </FONT>
<BR><FONT SIZE=3D2>&gt; is static).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; With this information, client and server =
initiate the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; security mechanims</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (e.g., initiate a TLS conection).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; When the client sends another SIP message =
to the outbound </FONT>
<BR><FONT SIZE=3D2>&gt; proxy, this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; time using the TLS connection, it includes =
a header field </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that contains</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the list obtained previously from the =
server. This way, the </FONT>
<BR><FONT SIZE=3D2>&gt; server can</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; check whether a MitM changes the list in =
order to perform a bid-down</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; attack.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Of course, this security negotiation =
mechanism requires that all the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; security mechanisms advertised provide =
integrity </FONT>
<BR><FONT SIZE=3D2>&gt; protection, at least.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Thank you,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Gonzalo</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Gonzalo =
Camarillo&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone :&nbsp; =
+358&nbsp; 9 299 33 71</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Oy L M Ericsson =
Ab&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile:&nbsp; +358 40 702 =
35 35</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Telecom =
R&amp;D&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; Fax&nbsp;&nbsp; :&nbsp; +358&nbsp; 9 299 30 =
52</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; FIN-02420 =
Jorvas&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Email =
:&nbsp; Gonzalo.Camarillo@ericsson.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
Finland&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
HREF=3D"http://www.hut.fi/~gonzalo" =
TARGET=3D"_blank">http://www.hut.fi/~gonzalo</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This list is for NEW development of the =
core SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Use sipping@ietf.org for new developments =
on the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C200D2.CAA6DAE0--

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



From daemon@optimus.ietf.org  Tue May 21 10:49:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12852
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 10:49:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA22575
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:49:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20854;
	Tue, 21 May 2002 10:26:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20772
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 10:26:09 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11752
	for <sip@ietf.org>; Tue, 21 May 2002 10:25:49 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4LEQ7s7004052
	for <sip@ietf.org>; Tue, 21 May 2002 16:26:07 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue May 21 16:26:01 2002 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <2JB43Z69>; Tue, 21 May 2002 16:26:01 +0200
Message-ID: <29F33B0CF787D51195FC0002A56B3DC10101B84F@efijont103>
From: "Vesa Torvinen (LMF)" <Vesa.Torvinen@lmf.ericsson.se>
To: "'James Undery'" <jundery@ubiquity.net>
Cc: "Jari Arkko (LMF)" <Jari.Arkko@lmf.ericsson.se>,
        "Gonzalo Camarillo Gonzalez (LMF)" <Gonzalo.Camarillo@lmf.ericsson.se>,
        sip <sip@ietf.org>
Subject: RE: [Sip] Reviewers for the sec-agree draft
Date: Tue, 21 May 2002 16:25:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Text in section 3.5 is supposed to address this issue: 

"If digest-integrity is chosen, the 494 (Security Agreement Required)
response will contain an HTTP authentication challenge. The client
MUST use the qos parameter possibly together with some variant of
MIME tunneling so that the Security-Verify header field in the
request is integrity protected in the MIME body. Note that digest
alone would not fulfill the minimum security requirements of this
specification."

We didn't want to specify how to use 'digest-integrity' exactly 
because this draft is related to negotiation - not individual 
mechanisms. Neither did we want to drop the mechanism from the 
list because someone can implement it using existing standards 
(e.g. MIME, B2BUA, etc). 

Vesa 

-----Original Message-----
From: James Undery [mailto:jundery@ubiquity.net]
Sent: 21. toukokuuta 2002 17:01
To: Gonzalo Camarillo; sip
Cc: Jari Arkko (LMF); Vesa Torvinen (LMF)
Subject: RE: [Sip] Reviewers for the sec-agree draft


Hi,

I'll have to admit myself of being guilty of not reading drafts
recently. But I'd note digest-integrity needs to be dropped as it
protects the body of messages only. If it can't be dropped a lpidf like
extension would be required 
(http://www.jdrosen.net/papers/draft-rosenberg-impp-lpidf-00.txt) to
place your headers in the body.

James

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: 21 May 2002 11:02
> To: sip
> Cc: Allison Mankin; Jari Arkko (LMF); Vesa Torvinen (LMF)
> Subject: [Sip] Reviewers for the sec-agree draft
> 
> 
> Hello folks,
> 
> we need SIP people willing to have a look at the new version 
> (01) of the
> sec-agree draft (released one week and a half ago).
> 
> http://standards.ericsson.net/gonzalo/papers/draft-ietf-sip-se
> c-agree-01.txt
> 
> As you proabbly know, the previous version (00) had some problems that
> were discovered during the iterim meeting in Vegas. The discovery of
> problems (such as a broken SIP syntax) at that point of time 
> (after the
> WGLC had finished) indicates that nobody in the SIP WG 
> bothered to read
> the document.
> 
> I am not saying that this draft is so interesting that everyone will
> enjoy reading it, but we would need at least a couple of 
> reviewers that
> are familiar with SIP and have the energy to review the document. We
> cannot let the SIP WG send documents to the IESG that have 
> major flaws!
> 
> 
> Here you have a brief summary of the changes we introduced to the new
> version of the draft (01):
> 
> The syntax has been fixed. Now it is allowed to have 
> different security
> mechanisms listed (separated by commas or in different lines). The
> previous draft used commas to separate security mechanism tokens. That
> made the header field non-SIP compliant.
> 
> The scope has been narrowed down. Before, the draft tried to 
> solve every
> security negotiation problem that could be found in a SIP network. Now
> the draft only tries to resolve the security negotiation 
> between a host
> and its next SIP hop (e.g., UA and the outbound proxy).
> 
> 
> The negotiation works as follows. The UA sends a SIP message 
> (typically
> OPTIONS) to its outbound proxy listing its security 
> capabilities (e.g.,
> TLS and IPSec). The outbound proxy sends a response with its own
> capabilities (it is important that the list in the server is static).
> With this information, client and server initiate the 
> security mechanims
> (e.g., initiate a TLS conection).
> 
> When the client sends another SIP message to the outbound proxy, this
> time using the TLS connection, it includes a header field 
> that contains
> the list obtained previously from the server. This way, the server can
> check whether a MitM changes the list in order to perform a bid-down
> attack.
> 
> Of course, this security negotiation mechanism requires that all the
> security mechanisms advertised provide integrity protection, at least.
> 
> Thank you,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May 21 10:50:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12916
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 10:50:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA22667
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 10:50:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21871;
	Tue, 21 May 2002 10:38:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21843
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 10:38:50 -0400 (EDT)
Received: from gbnewp0915s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12377
	for <sip@ietf.org>; Tue, 21 May 2002 10:38:31 -0400 (EDT)
Received: from mailhost.eu.ubiquity.net by gbnewp0915s1.eu.ubiquity.net
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 May 2002 14:39:12 UT
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] Reviewers for the sec-agree draft
Date: Tue, 21 May 2002 15:41:22 +0100
Message-ID: <45730E094814E44488F789C1CDED27AEC552F5@GBNEWP0758M.eu.ubiquity.net>
Thread-Topic: [Sip] Reviewers for the sec-agree draft
Thread-Index: AcIA084N4VvsSfiFTL+cFr+3/OA/9wAAGoVQ
From: "James Undery" <jundery@ubiquity.net>
To: "Vesa Torvinen (LMF)" <Vesa.Torvinen@lmf.ericsson.se>
Cc: "Jari Arkko (LMF)" <Jari.Arkko@lmf.ericsson.se>,
        "Gonzalo Camarillo Gonzalez (LMF)" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "sip" <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA21844
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: Vesa Torvinen (LMF) [mailto:Vesa.Torvinen@lmf.ericsson.se]
> Sent: 21 May 2002 15:26
> To: James Undery
> Cc: Jari Arkko (LMF); Gonzalo Camarillo Gonzalez (LMF); sip
> Subject: RE: [Sip] Reviewers for the sec-agree draft
> 
> 
> Text in section 3.5 is supposed to address this issue: 
> 
> "If digest-integrity is chosen, the 494 (Security Agreement Required)
> response will contain an HTTP authentication challenge. The client
> MUST use the qos parameter possibly together with some variant of

The word possibly above worries me, it'd also be nice to make the
mechanism explicit e.g. 'sipfrags' as Sanjoy suggested.

> MIME tunneling so that the Security-Verify header field in the
> request is integrity protected in the MIME body. Note that digest
> alone would not fulfill the minimum security requirements of this
> specification."
> 
> We didn't want to specify how to use 'digest-integrity' exactly 
> because this draft is related to negotiation - not individual 
> mechanisms. Neither did we want to drop the mechanism from the 
> list because someone can implement it using existing standards 
> (e.g. MIME, B2BUA, etc). 

I think a small amount of usage is required e.g. S/MIME protection MUST
include any Security-* headers present. (This is mainly implicit at the
moment.)

James

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



From daemon@optimus.ietf.org  Tue May 21 11:48:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15369
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 11:48:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA25441
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 11:48:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24165;
	Tue, 21 May 2002 11:19:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24086
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 11:19:54 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14523;
	Tue, 21 May 2002 11:19:34 -0400 (EDT)
Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LFJYa10120;
	Tue, 21 May 2002 10:19:34 -0500 (CDT)
Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KKXXTP1S>; Tue, 21 May 2002 10:19:37 -0500
Message-ID: <EF1056F8EB4ED511B8FB0002A56079D401E5B098@zrc2c014.us.nortel.com>
From: "Sriram Parameswar"<sriramp@nortelnetworks.com>
To: "'iesg@ietf.org'" <iesg@ietf.org>, sip@ietf.org
Subject: Re:[Sip] Last Call: The Refer Method to Proposed Standard
Date: Tue, 21 May 2002 10:19:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C200DA.E6433570"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

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

Hi:

A couple of comments on the Refer draft.

1. It would be good to add REFER to the table in Section 3 and put "m" for
Mandatory against the Refer-To header. This would clarify what is in the
text just below - also its in keeping with other draft published (example:
events draft section 8.2).

2. I had sent a similar comment to the list on 4/26/2002. Section 4.2.2 and
section 8.2 of the Events draft
http://www.ietf.org/internet-drafts/draft-ietf-sip-events-05.txt (reproduced
below for convenience) show that the Subscription State as a mandatory
header in a NOTIFY method. It would be good to include these in the
examples. I would also like to suggest a small discussion on the semantics
of the Subscripton-State header, they will be useful especially in
out-of-band REFER's to give the referor (originator of REFER) some idea when
he could retry a REFER. For example the discussion could read:

	 The NOTIFY to a REFER MUST contain a Subscription-State which
indicates the status of the subscription. Typically for a successful REFER,
the NOTIFY SHOULD contain a Subscription-State of "terminated". It may not
contain a reason code for the termination, however if one exists it SHOULD
be "timeout" (for success cases). For cases where the REFER failed or was
rejected (especially out-of-band REFERs) the Subscription-State header with
its"reason" and "retry-after" parameters provides important information as
to when the REFER may be retried, see the events drafts [EVENTS] for the
semantics of the reason codes and the "retry-after" parameters. Please note
that the message/sipfrag body will contain the specific reason the REFER
failed.

Thanks,

Sriram Parameswar

----------------------Section 4.2.2 Events
draft------------------------------
NOTIFY requests MUST contain a "Subscription-State" header with a value of
"active", "pending", or "terminated". ...If the value of the
"Subscription-State" header is "terminated", the notifier SHOULD also
include a "reason" parameter. The notifier MAY also include a "retry-after"
parameter, where appropriate.
----------Section 8.2 Events draft
Header field 		where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 
Subscription-State 	R                     -       -        -       -
-        -     -        -       m 



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


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>Re:[Sip] Last Call: The Refer Method to Proposed =
Standard</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2 FACE=3D"Arial">A couple of comments on the Refer =
draft.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. It would be good to add REFER to =
the table in Section 3 and put &quot;m&quot; for Mandatory against the =
Refer-To header. This would clarify what is in the text just below - =
also its in keeping with other draft published (example: events draft =
section 8.2).</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. I had sent a similar comment to the =
list on 4/26/2002. Section 4.2.2 and section 8.2 of the Events draft <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-sip-events-05.txt=
" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-sip-eve=
nts-05.txt</A> (reproduced below for convenience) show that the =
Subscription State as a mandatory header in a NOTIFY method. It would =
be good to include these in the examples. I would also like to suggest =
a small discussion on the semantics of the Subscripton-State header, =
they will be useful especially in out-of-band REFER's to give the =
referor (originator of REFER) some idea when he could retry a REFER. =
For example the discussion could read:</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<FONT SIZE=3D2 =
FACE=3D"Arial"> The NOTIFY to a REFER MUST contain a Subscription-State =
which indicates the status of the subscription. Typically for a =
successful REFER, the NOTIFY SHOULD contain a Subscription-State of =
&quot;terminated&quot;. It may not contain a reason code for the =
termination, however if one exists it SHOULD be &quot;timeout&quot; =
(for success cases). For cases where the REFER failed or was rejected =
(especially out-of-band REFERs) the Subscription-State header with =
its&quot;reason&quot; and &quot;retry-after&quot; parameters provides =
important information as to when the REFER may be retried, see the =
events drafts [EVENTS] for the semantics of the reason codes and the =
&quot;retry-after&quot; parameters. Please note that the =
message/sipfrag body will contain the specific reason the REFER =
failed.</FONT></P>

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

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

<P><FONT SIZE=3D2 FACE=3D"Arial">----------------------Section 4.2.2 =
Events draft------------------------------</FONT>
<BR><FONT FACE=3D"Times New Roman">NOTIFY requests MUST contain a =
&quot;Subscription-State&quot; header with a value of =
&quot;active&quot;, &quot;pending&quot;, or &quot;terminated&quot;. =
...If the value of the &quot;Subscription-State&quot; header is =
&quot;terminated&quot;, the notifier SHOULD also include a =
&quot;reason&quot; parameter. The notifier MAY also include a =
&quot;retry-after&quot; parameter, where appropriate.</FONT></P>

<P><FONT FACE=3D"Times New Roman">----------Section 8.2 Events =
draft</FONT>
<BR><FONT FACE=3D"Times New Roman">Header field &nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; where proxy ACK BYE CAN INV =
OPT REG PRA SUB NOT </FONT>
<BR><FONT FACE=3D"Times New Roman">Subscription-State =
&nbsp;&nbsp;&nbsp;&nbsp; =
R&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; m </FONT>
</P>
<BR>
<BR>

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

</BODY>
</HTML>
------_=_NextPart_001_01C200DA.E6433570--

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



From daemon@optimus.ietf.org  Tue May 21 12:26:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17441
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 12:26:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA29270
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 12:26:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28106;
	Tue, 21 May 2002 12:11:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28081
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 12:11:47 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16307
	for <sip@ietf.org>; Tue, 21 May 2002 12:11:28 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.234])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4LGCbYH017642;
	Tue, 21 May 2002 12:12:37 -0400 (EDT)
Message-ID: <3CEA7198.E7B0BE6B@dynamicsoft.com>
Date: Tue, 21 May 2002 12:11:04 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ben Campbell <bcampbell@dynamicsoft.com>
CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, sip@ietf.org
Subject: Re: [Sip] Message draft changes
References: <HNEOJECGFHIABDLENMMCGECACJAA.bcampbell@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Ben Campbell wrote:
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> 
> [snip]
> 
> > Actually, I think you mean to say that it is very unlikely that the UA
> > will know the path MTU for reaching every sip device. I agree, but its
> > not the case that it needs to know. In most usages, the UA will talk
> to
> > an outbound proxy, and it will know the path MTU to the outbound
> proxy.
> > Its determination about whether to use UDP or TCP would then be based
> on
> > this specific path MTU.
> >
> 
> Yes, that is what I mean. Why does only the first hop matter for the
> UDP/TCP
> decision?

Because each hop (in the SIP sense) makes an independent decision about
which transport to use, and that decision is a function of the size of
the request and the path MTU to the next hop (in the sip sense).

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Tue May 21 13:01:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19347
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 13:01:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA02196
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 13:01:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29063;
	Tue, 21 May 2002 12:24:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29032
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 12:23:57 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17063
	for <sip@ietf.org>; Tue, 21 May 2002 12:23:37 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4LGNJPI008341;
	Tue, 21 May 2002 09:23:20 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABS02255;
	Tue, 21 May 2002 09:20:18 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03438; Tue, 21 May 2002 09:23:19 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15594.29815.153064.848806@thomasm-u1.cisco.com>
Date: Tue, 21 May 2002 09:23:19 -0700 (PDT)
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Ben Campbell <bcampbell@dynamicsoft.com>, hisham.khartabil@nokia.com,
        aki.niemi@nokia.com, sip@ietf.org
Subject: Re: [Sip] Message draft changes
In-Reply-To: <3CEA7198.E7B0BE6B@dynamicsoft.com>
References: <HNEOJECGFHIABDLENMMCGECACJAA.bcampbell@dynamicsoft.com>
	<3CEA7198.E7B0BE6B@dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
 > Because each hop (in the SIP sense) makes an independent decision about
 > which transport to use, and that decision is a function of the size of
 > the request and the path MTU to the next hop (in the sip sense).

   Well then, SIP imitates the net again. The net has path 
   MTU discovery to get around this problem; why shouldn't
   SIP?

		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 daemon@optimus.ietf.org  Tue May 21 14:49:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24236
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 14:49:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA07921
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 14:49:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06638;
	Tue, 21 May 2002 14:26:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06599
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 14:26:21 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23246
	for <sip@ietf.org>; Tue, 21 May 2002 14:26:02 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id UAA20168;
	Tue, 21 May 2002 20:26:01 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id UAA16484;
	Tue, 21 May 2002 20:24:07 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <K94LM939>; Tue, 21 May 2002 11:21:21 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DB7@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'adam@dynamicsoft.com'" <adam@dynamicsoft.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: [SIP] NOTIFY request MUST contain an Expires header?
Date: Tue, 21 May 2002 11:21:14 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

draft-ietf-sip-events states that 200-class responses to SUBSCRIBE requests
MUST contain an "Expires" header, which defines the duration of the
subscription. In the case of forking, the subscriber will receive only one
200-class response. If the subscriber allows multiple subscriptions and
installs further subscriptions when receiving NOTIFY requests, the durations
of these subscriptions will not be known to the subscriber as the 200-class
responses for these subscriptions would have been dropped at the forking
proxy. I think the Expires header should be made mandatory in NOTIFY.

Please excuse me if this has been brought up before.


Regards,

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



From daemon@optimus.ietf.org  Tue May 21 15:54:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26864
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 15:54:51 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA11041
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 15:55:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10160;
	Tue, 21 May 2002 15:34:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00073
	for <sip@optimus.ietf.org>; Mon, 20 May 2002 20:34:46 -0400 (EDT)
Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24691
	for <sip@ietf.org>; Mon, 20 May 2002 20:34:27 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by ihemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4L0Yh209090
	for <sip@ietf.org>; Mon, 20 May 2002 20:34:44 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <K9QX1DZG>; Mon, 20 May 2002 19:34:43 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C0296C9EF@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: Dean Willis <dean.willis@softarmor.com>,
        Cullen Jennings
	 <fluffy@cisco.com>,
        "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>, sip@ietf.org
Subject: RE: [Sip] Expert Review: draft-henrikson-sip-original-dialog-id-0
	1.txt
Date: Mon, 20 May 2002 19:34:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Dean,

Thank you for sending back the responses on my behalf when I was away from my email.
I will be updating the draft to give a better explation of the motivation.

Eric

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Monday, May 13, 2002 10:37 PM
To: Cullen Jennings; Henrikson, Eric H (Eric); sip@ietf.org
Subject: Re: [Sip] Expert Review:
draft-henrikson-sip-original-dialog-id-01.txt



The proxy doesn't correlate it. The billing system correlates, using the
"original call ID"

For example:

Here's an example:

You go through an S-CSCF, through an anonymizer AS and out to a partner
company (but we still want you to be anonymized from them so they don't
send you spam later) for gateway services. The partner company sends
charging records back. We want to be able to correlate the charging
records (keyed by OrigID) with the records written by the S-CSCF.
Actually, I just realized that this anonymization trick would be useful
for statistical "blind sampling" of the veracity of a partner's billing
system. You heard it first here folks!

DCS had a very similar header called the DCS billing ID or something
like that.

--
Dean


----- Original Message -----
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>; "Dean Willis"
<dean.willis@softarmor.com>; <sip@ietf.org>
Sent: Monday, May 13, 2002 10:55 PM
Subject: RE: [Sip] Expert Review:
draft-henrikson-sip-original-dialog-id-01.txt


>
> I don't understand why the proxy, P1, that sent the call to the AS (a
> B2BUA), would need to correlate the call that came back from the AS
with the
> original call that P1 sent to the AS. Are there any requirements of
what we
> are trying to solve here?
>
>
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of
> > Henrikson, Eric H (Eric)
> > Sent: Tuesday, May 07, 2002 9:55 AM
> > To: Dean Willis; sip@ietf.org
> > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com;
'Allison
> > Mankin'; Drage, Keith (Keith)
> > Subject: [Sip] Expert Review:
> > draft-henrikson-sip-original-dialog-id-01.txt
> >
> >
> > Attached is revision 01 of the original-dialog-id draft.
> >
> > Please return comments by May 10, 2002.
> >
> >
> > Thank you.
> > Eric Henrikson
> >
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: Wednesday, May 01, 2002 6:38 AM
> > To: sip@ietf.org
> > Cc: jo@ipdialog.com; brian.rosen@marconi.com; Rohan@cicso.com;
'Allison
> > Mankin'; Drage, Keith (Keith); Henrikson, Eric H (Eric)
> > Subject: Expert Review:
draft-henrikson-sip-original-dialog-id-00.txt
> >
> >
> >
> > The SIP working group has been asked to provide expert review of
> > draft-henrikson-sip-original-dialog-id. This documents a P-header
used
> > in 3GPP to associate dialogs across a 3GPP application server acting
as
> > a back-to-back user agent.
> >
> > We'd like to complete expert review by May 10, 2002.
> >
> > Please copy your comments to the list and to Keith Drage and Eric
> > Henrikson, who will coordinate responses and edit the draft
> > apporpriately.
> >
> > Thanks,
> >
> > --
> > 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 daemon@optimus.ietf.org  Tue May 21 16:00:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27116
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 16:00:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA11543
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:00:49 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10868;
	Tue, 21 May 2002 15:48:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10839
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 15:47:55 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26553
	for <sip@ietf.org>; Tue, 21 May 2002 15:47:36 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A445C1AA0154; Tue, 21 May 2002 15:47:17 -0400
Message-ID: <00f701c20100$1a2a4200$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Dean Willis" <dean.willis@softarmor.com>, <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        <bernhard.honeisen@nokia.com>
References: <005501c2003e$2b9f7cc0$1d036e3f@TXDWILLIS2>
Subject: Re: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt
Date: Tue, 21 May 2002 15:45:46 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

A couple minor nits:

1) The RFC 2119 reference paragraph should be a separate section as opposed
to being part of the Abstract.

2) Section 2, 1st para, last sentence: s/to to/to/

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>; <brian.rosen@marconi.com>; <jo@ipdialog.com>;
<bernhard.honeisen@nokia.com>
Sent: Monday, May 20, 2002 4:37 PM
Subject: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt


>
> I'd like to wrap up:
>
> http://www.ietf.org/internet-drafts/draft-willis-sip-scvrtdisco-04.txt
>
>
> I think this version accomodates all changes requested to date.
>
> Anybody still have anything to add? Speak now . . .
>
> Thanks,
>
> --
> 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 daemon@optimus.ietf.org  Tue May 21 16:02:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27202
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 16:02:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA11683
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:02:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10599;
	Tue, 21 May 2002 15:39:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10528
	for <sip@optimus.ietf.org>; Tue, 21 May 2002 15:39:16 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26241;
	Tue, 21 May 2002 15:38:57 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A25A445201F6; Tue, 21 May 2002 15:39:06 -0400
Message-ID: <00bf01c200fe$f65edb20$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: <iesg@ietf.org>
Cc: "Robert Sparks" <rsparks@dynamicsoft.com>, <sip@ietf.org>,
        "Rohan Mahy" <rohan@cisco.com>
References: <200205201659.MAA18283@ietf.org>
Subject: Re: [Sip] Last Call: The Refer Method to Proposed Standard
Date: Tue, 21 May 2002 15:37:37 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I found a few minor problems with a couple of these documents. I apologize
for the lateness of these comments.

draft-ietf-sip-refer-04.txt:
1) I agree that the title should be changed to "The SIP Refer Method".

2) Section 4
2a) It refers to tables 4 & 5 in the SIP spec (RFC 3261). It should be
tables 2 and 3.

2b) 4th line: change "each mandatory" to "mandatory" (there used to be 2
headers, but now just one <Refer-To>)

2c) last sentence: change "enc and e-e columns" to "proxy column". (The enc
& e-e columns in RFC 2543 were replaced by the proxy column in RFC 3261).

3) Section 10. 3rd paragraph says that method names are not registered with
IANA, but according to section 27.4 of RFC 3261, they now are registered.
This spec needs to register the REFER method.

draft-ietf-sip-replaces-02.txt:
1) The examples on page 4 and page 10 include a Referred-By header. This
header was removed from the REFER spec and therefore has not been defined.
It should be removed from the examples.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
bpenfield@acmepacket.com

----- Original Message -----
From: "The IESG" <iesg-secretary@ietf.org>
To: <IETF-Announce:>
Cc: <sip@ietf.org>
Sent: Monday, May 20, 2002 12:59 PM
Subject: [Sip] Last Call: The Refer Method to Proposed Standard


>
> The IESG has received a request from the Session Initiation Protocol
> Working Group to consider publication of the following Internet-Drafts
> as Proposed Standards:
>
>  o The Refer Method
> <draft-ietf-sip-refer-04.txt>
>  o The Session Inititation Protocol (SIP)
> <draft-ietf-sip-replaces-02.txt>
>  o The Reason Header Field for the Session Initiation Protocol
> <draft-ietf-sip-reason-01.txt>
>  o Internet Media Types message/sipfrag
> <draft-sparks-sip-mimetypes-03.txt>
>  o SIP Extension for Registering Non-Adjacent Contacts
> <draft-willis-sip-path-06.txt>
>
>
> The IESG will also consider publication of Best Current Practices for
> Third Party Call Control in the Session Initiation Protocol
> <draft-ietf-sipping-3pcc-00.txt> as a BCP.
>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002.
>
> Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt
> http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt
> http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@ns.ietf.org  Tue May 21 16:45:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29483
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 16:45:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA13657
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:45:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12636;
	Tue, 21 May 2002 16:29:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12604
	for <sip@ns.ietf.org>; Tue, 21 May 2002 16:29:08 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28690
	for <sip@ietf.org>; Tue, 21 May 2002 16:28:48 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4LKRFd17099;
	Tue, 21 May 2002 15:27:15 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <aki.niemi@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <bcampbell@dynamicsoft.com>, <hgs@cs.columbia.edu>, <mat@cisco.com>,
        <seancolson@yahoo.com>, <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Tue, 21 May 2002 15:26:47 -0500
Message-ID: <00ac01c20105$d68d6490$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED1F@esebe013.NOE.Nokia.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Aki says:
> I totally agree. However, I know of email lists / systems, 
> which have local policy governing the sizes of attachments. I 
> feel such optionality is currently missing from the MESSAGE 
> draft. For example, the default content-indirection policy 
> seems to be that the sender always performs it. How about if 
> this was part of the recipient's service offering? Sort of 
> like a safeguard for UAs behind the low-capacity links.

It's called a B2BUA or "in network UA" -- it accepts the SIP message,
stores the content, and sends a new message (containing a pointer) on
towards the user. Like other B2BUA-ish things, this capability is
implicit in the current specification.

But yeah, it's a cool and useful service opportunity.

I use something very similar to send snippets of large emails to my
mobile devices. Then I can look at the snippets and guess if it's worth
downloading full text at $10/MB . . .

--
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 daemon@ns.ietf.org  Tue May 21 16:50:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29758
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 16:50:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA13754
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 16:50:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12584;
	Tue, 21 May 2002 16:28:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA12550
	for <sip@ns.ietf.org>; Tue, 21 May 2002 16:28:14 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28626
	for <sip@ietf.org>; Tue, 21 May 2002 16:27:54 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4LKRDd17096;
	Tue, 21 May 2002 15:27:14 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Ben Campbell'" <bcampbell@dynamicsoft.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <hisham.khartabil@nokia.com>, <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: [Sip] Message draft changes
Date: Tue, 21 May 2002 15:26:47 -0500
Message-ID: <00ab01c20105$d62ec9d0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <HNEOJECGFHIABDLENMMCGECACJAA.bcampbell@dynamicsoft.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> > Actually, I think you mean to say that it is very unlikely 
> that the UA 
> > will know the path MTU for reaching every sip device. I 
> agree, but its 
> > not the case that it needs to know. In most usages, the UA 
> will talk 
> > to an outbound proxy, and it will know the path MTU to the outbound 
> > proxy. Its determination about whether to use UDP or TCP 
> would then be 
> > based on this specific path MTU.
> >
> 
> Yes, that is what I mean. Why does only the first hop matter 
> for the UDP/TCP decision?

Because the definition of "proxy" is to "delegate decision-making to
another entity.". The crux of the argument is that once it has left the
UA and gotten safely to the first-hop-proxy, what to do NEXT is now the
proxy's problem. Maybe that next hop proxy implements flow control for
UDP by tunnelling all UDP requests over SSH. Maybe it uses SCTP. But
it's the only one who really KNOWS.

--
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 daemon@ns.ietf.org  Tue May 21 17:00:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00302
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 17:00:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA15037
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 17:00:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13532;
	Tue, 21 May 2002 16:43:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13503
	for <sip@ns.ietf.org>; Tue, 21 May 2002 16:43:07 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29384
	for <sip@ietf.org>; Tue, 21 May 2002 16:42:47 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4LKg3d17186;
	Tue, 21 May 2002 15:42:03 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Bob Penfield'" <bpenfield@acmepacket.com>, <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        <bernhard.honeisen@nokia.com>
Subject: RE: [Sip] Poll: Expert Review of draft-willis-sip-scvrtdisco-04.txt
Date: Tue, 21 May 2002 15:41:38 -0500
Message-ID: <00ad01c20107$e83bd7b0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <00f701c20100$1a2a4200$2300000a@acmepacket.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Bob noted:
> A couple minor nits:
> 
> 1) The RFC 2119 reference paragraph should be a separate 
> section as opposed to being part of the Abstract.


I wondered about this too, but I copied the section wholsale from some
moderately recently published RFC (which, I don't recall, just grabbed a
number out of the RFC pool). However, further review shows that the
majority of newest documents include such annotation in a separate
section  such as "Conventions used in this document" (RFC 3206) or
"Terminology" (RFC 3207).


 
> 2) Section 2, 1st para, last sentence: s/to to/to/

Oops oops.


I will fix both in next, hopefully final rev.


ANYBODY HAVE ANYTHING ELSE?

--
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 daemon@ns.ietf.org  Tue May 21 17:12:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00808
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 17:12:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA15692
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 17:12:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13911;
	Tue, 21 May 2002 16:54:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13882
	for <sip@ns.ietf.org>; Tue, 21 May 2002 16:54:25 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29900
	for <sip@ietf.org>; Tue, 21 May 2002 16:54:04 -0400 (EDT)
Received: from txbcampbell (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with SMTP id g4LKsFX92799;
	Tue, 21 May 2002 15:54:15 -0500 (CDT)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <hisham.khartabil@nokia.com>, <aki.niemi@nokia.com>, <sip@ietf.org>
Subject: RE: [Sip] Message draft changes
Date: Tue, 21 May 2002 15:54:00 -0500
Message-ID: <HNEOJECGFHIABDLENMMCMEDDCJAA.bcampbell@dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <00ab01c20105$d62ec9d0$1d036e3f@TXDWILLIS2>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, May 21, 2002 3:27 PM
> To: 'Ben Campbell'; 'Jonathan Rosenberg'
> Cc: hisham.khartabil@nokia.com; aki.niemi@nokia.com; sip@ietf.org
> Subject: RE: [Sip] Message draft changes
>
>
> > > Actually, I think you mean to say that it is very unlikely
> > that the UA
> > > will know the path MTU for reaching every sip device. I
> > agree, but its
> > > not the case that it needs to know. In most usages, the UA
> > will talk
> > > to an outbound proxy, and it will know the path MTU to the outbound
> > > proxy. Its determination about whether to use UDP or TCP
> > would then be
> > > based on this specific path MTU.
> > >
> >
> > Yes, that is what I mean. Why does only the first hop matter
> > for the UDP/TCP decision?
>
> Because the definition of "proxy" is to "delegate decision-making to
> another entity.". The crux of the argument is that once it has left the
> UA and gotten safely to the first-hop-proxy, what to do NEXT is now the
> proxy's problem. Maybe that next hop proxy implements flow control for
> UDP by tunnelling all UDP requests over SSH. Maybe it uses SCTP. But
> it's the only one who really KNOWS.
>

Right, of course--I was confusing myself with the stonger requirement for
MESSAGE, where the fact that some downstream proxy could convert to UDP
causes us to limit request size to 1300. The original question comes from
feedback suggesting this size was unnecesarily arbitrary.

It was also suggested that it should be relative to path MTU to the first
hop. But I am not sure the first hop path MTU is relevant. The real goal is
to keep the size below the path MTU of _all_ hops, _most_ of the time. The
first hop mtu tells you nothing about the rest.

I assume the 1300 default was chosen for SIP in general because of a belief
that, if you have no knowledge of MTU size, that value is a reasonable SWAG.
I don't see how we can do any better for MESSAGE.

> --
> 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 daemon@ns.ietf.org  Tue May 21 17:43:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02027
	for <sip-archive@odin.ietf.org>; Tue, 21 May 2002 17:43:53 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA17039
	for sip-archive@odin.ietf.org; Tue, 21 May 2002 17:44:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16117;
	Tue, 21 May 2002 17:29:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16088
	for <sip@ns.ietf.org>; Tue, 21 May 2002 17:29:07 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01469
	for <sip@ietf.org>; Tue, 21 May 2002 17:28:47 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.234])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4LLU6YH018164;
	Tue, 21 May 2002 17:30:07 -0400 (EDT)
Message-ID: <3CEABC01.6DC423D9@dynamicsoft.com>
Date: Tue, 21 May 2002 17:28:34 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tan Ya-Ching ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
CC: "'adam@dynamicsoft.com'" <adam@dynamicsoft.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [SIP] NOTIFY request MUST contain an Expires header?
References: <5B4D0C5BA65ECA46969C1419122317E6E74DB7@mchh161e>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
> Hi,
> 
> draft-ietf-sip-events states that 200-class responses to SUBSCRIBE
> requests
> MUST contain an "Expires" header, which defines the duration of the
> subscription. In the case of forking, the subscriber will receive only
> one
> 200-class response. If the subscriber allows multiple subscriptions and
> installs further subscriptions when receiving NOTIFY requests, the
> durations
> of these subscriptions will not be known to the subscriber as the
> 200-class
> responses for these subscriptions would have been dropped at the forking
> proxy. I think the Expires header should be made mandatory in NOTIFY.

There is an expires parameter in the Subscription-State header which
conveys the expiration of the subscription. The decision was made not to
use the Expires header for this purpose, since Expires refers to the
message its carried in, and it is not the NOTIFY which is expiring, but
the subscription.

-Jonathan R.

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

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



From daemon@ns.ietf.org  Wed May 22 01:56:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19255
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 01:56:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA16451
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 01:56:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16092;
	Wed, 22 May 2002 01:39:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16033
	for <sip@ns.ietf.org>; Wed, 22 May 2002 01:39:19 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18627
	for <sip@ietf.org>; Wed, 22 May 2002 01:39:00 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4M5ccuF020878;
	Tue, 21 May 2002 22:38:38 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACY93242;
	Tue, 21 May 2002 22:39:00 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <sip@ietf.org>, <miguel.a.garcia@ericsson.com>
Date: Tue, 21 May 2002 22:39:27 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCEEEBCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <200205211130.HAA04901@ietf.org>
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-garcia-sip-visited-network-id-01.txt and history requirements
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


It seems to me that the mechanism that meets the requirements of the history
requirements (draft-watson-sipping-req-history-01.txt) would also solve this
problem. Do we want two things to do the same thing?

Cullen


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



From daemon@ns.ietf.org  Wed May 22 01:56:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19276
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 01:56:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id BAA16474
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 01:56:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16108;
	Wed, 22 May 2002 01:39:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA16039
	for <sip@ns.ietf.org>; Wed, 22 May 2002 01:39:20 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18632
	for <sip@ietf.org>; Wed, 22 May 2002 01:39:02 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4M5cnEU004775;
	Tue, 21 May 2002 22:38:49 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACY93243;
	Tue, 21 May 2002 22:39:00 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <sip@ietf.org>, <miguel.a.garcia@ericsson.com>
Date: Tue, 21 May 2002 22:39:27 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCGEEBCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-garcia-sip-called-party-id-01.txt and history requirements
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


It seems to me that the mechanism that meets the requirements of the history
requirements (draft-watson-sipping-req-history-01.txt) would also solve this
problem. Do we want two things to do the same thing?

Cullen


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



From daemon@ns.ietf.org  Wed May 22 03:03:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14458
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 03:03:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA02727
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 03:03:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01591;
	Wed, 22 May 2002 02:46:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01560
	for <sip@ns.ietf.org>; Wed, 22 May 2002 02:46:12 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13717
	for <sip@ietf.org>; Wed, 22 May 2002 02:45:37 -0400 (EDT)
From: aki.niemi@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4M6iLY01596
	for <sip@ietf.org>; Wed, 22 May 2002 09:44:21 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b03f9831bac158f25079@esvir05nok.ntc.nokia.com>;
 Wed, 22 May 2002 09:45:07 +0300
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 22 May 2002 09:45:07 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Wed, 22 May 2002 09:45:06 +0300
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED22@esebe013.NOE.Nokia.com>
Thread-Topic: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Thread-Index: AcIBBlJzEHPB5G1QREm9rgUjlcxrkQAVMReQ
To: <dean.willis@softarmor.com>, <jdrosen@dynamicsoft.com>
Cc: <bcampbell@dynamicsoft.com>, <hgs@cs.columbia.edu>, <mat@cisco.com>,
        <seancolson@yahoo.com>, <sip@ietf.org>
X-OriginalArrivalTime: 22 May 2002 06:45:07.0511 (UTC) FILETIME=[360B1470:01C2015C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA01561
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> Aki says:
> > I totally agree. However, I know of email lists / systems, 
> > which have local policy governing the sizes of attachments. I 
> > feel such optionality is currently missing from the MESSAGE 
> > draft. For example, the default content-indirection policy 
> > seems to be that the sender always performs it. How about if 
> > this was part of the recipient's service offering? Sort of 
> > like a safeguard for UAs behind the low-capacity links.
> 
> It's called a B2BUA or "in network UA" -- it accepts the SIP message,
> stores the content, and sends a new message (containing a pointer) on
> towards the user. Like other B2BUA-ish things, this capability is
> implicit in the current specification.

Yes, the capability is there, but since the sender itself is always responsible for enforcing the 1300 byte size limitation of the MESSAGE request, this effectively negates any need for such a UA in the network.

I was saying that it would be nice if the actual enforcement of the size limit could be relaxed, so that it could also be up to such a store-and-forward UA in the network. However, having said that I can't think of a simple way to make this happen.
 
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 daemon@ns.ietf.org  Wed May 22 04:15:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17036
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 04:15:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA06097
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 04:15:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03782;
	Wed, 22 May 2002 03:27:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA03751
	for <sip@ns.ietf.org>; Wed, 22 May 2002 03:27:28 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15381
	for <sip@ietf.org>; Wed, 22 May 2002 03:25:59 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4M7Qbk03280
	for <sip@ietf.org>; Wed, 22 May 2002 10:26:37 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b041f0463ac158f24077@esvir04nok.ntc.nokia.com>;
 Wed, 22 May 2002 10:26:05 +0300
Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 22 May 2002 10:26:03 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 22 May 2002 10:26:02 +0300
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Sip] Message draft changes
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 22 May 2002 10:26:01 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791CC@esebe019.NOE.Nokia.com>
Thread-Topic: [Sip] Message draft changes
Thread-Index: AcIBCbFZb7Qia8YMSXuozHZh7c8NKQAV/JuA
To: <bcampbell@dynamicsoft.com>, <dean.willis@softarmor.com>,
        <jdrosen@dynamicsoft.com>
Cc: <aki.niemi@nokia.com>, <sip@ietf.org>
X-OriginalArrivalTime: 22 May 2002 07:26:03.0000 (UTC) FILETIME=[EDA0F780:01C20161]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA03752
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Tuesday, May 21, 2002 11:54 PM
> To: Dean Willis; 'Jonathan Rosenberg'
> Cc: Khartabil Hisham (NMP/Helsinki); Niemi Aki (NET/Espoo); 
> sip@ietf.org
> Subject: RE: [Sip] Message draft changes
> 

> 
> I assume the 1300 default was chosen for SIP in general 
> because of a belief
> that, if you have no knowledge of MTU size, that value is a 
> reasonable SWAG.
> I don't see how we can do any better for MESSAGE.

There is no need to mention anything about that in the MESSAGE draft. A reference to RFC3261 is enough for this issue.

Regards,
Hisham

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



From daemon@optimus.ietf.org  Wed May 22 04:53:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17824
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 04:53:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA07906
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 04:53:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05458;
	Wed, 22 May 2002 04:00:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05401
	for <sip@ns.ietf.org>; Wed, 22 May 2002 04:00:25 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16542
	for <sip@ietf.org>; Wed, 22 May 2002 04:00:06 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4M80Os7000661;
	Wed, 22 May 2002 10:00:24 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4M80N9q016726;
	Wed, 22 May 2002 11:00:23 +0300 (EET DST)
Message-ID: <3CEB5017.C835BE93@ericsson.com>
Date: Wed, 22 May 2002 11:00:23 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: sip@ietf.org
References: <DLEHICEBMNEIPCACNLPCGEEBCDAA.fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: draft-garcia-sip-called-party-id-01.txt and history requirements
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Cullen:

I am aware that this P- header may be part of the history. However, as you know,
the history is still in requirements phase, whereas 3GPP Release 5 needs a 
solution by June timeframe.

Miguel

Cullen Jennings wrote:
> 
> It seems to me that the mechanism that meets the requirements of the history
> requirements (draft-watson-sipping-req-history-01.txt) would also solve this
> problem. Do we want two things to do the same thing?
> 
> Cullen

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Wed May 22 04:55:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17902
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 04:55:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA07961
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 04:55:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05500;
	Wed, 22 May 2002 04:00:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05446
	for <sip@ns.ietf.org>; Wed, 22 May 2002 04:00:28 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16546
	for <sip@ietf.org>; Wed, 22 May 2002 04:00:09 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4M80Qs7000671;
	Wed, 22 May 2002 10:00:26 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4M80Q9q016731;
	Wed, 22 May 2002 11:00:26 +0300 (EET DST)
Message-ID: <3CEB501A.9B6B6FED@ericsson.com>
Date: Wed, 22 May 2002 11:00:26 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: sip@ietf.org
References: <DLEHICEBMNEIPCACNLPCEEEBCDAA.fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and history requirements
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Cullen:

I am aware that this P- header may be part of the history. However, as you know,
the history is still in requirements phase, whereas 3GPP Release 5 needs a 
solution by June timeframe.

Miguel

Cullen Jennings wrote:
> 
> It seems to me that the mechanism that meets the requirements of the history
> requirements (draft-watson-sipping-req-history-01.txt) would also solve this
> problem. Do we want two things to do the same thing?
> 
> Cullen

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Wed May 22 05:16:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18287
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 05:16:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA09012
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 05:16:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06427;
	Wed, 22 May 2002 04:23:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06397
	for <sip@ns.ietf.org>; Wed, 22 May 2002 04:23:54 -0400 (EDT)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17326
	for <sip@ietf.org>; Wed, 22 May 2002 04:23:35 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA11240;
	Wed, 22 May 2002 10:23:51 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA16791;
	Wed, 22 May 2002 10:23:52 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LL4YTHSJ>; Wed, 22 May 2002 10:23:54 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DC8@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "'adam@dynamicsoft.com'" <adam@dynamicsoft.com>,
        "'sip@ietf.org'"
	 <sip@ietf.org>
Subject: RE: [SIP] NOTIFY request MUST contain an Expires header?
Date: Wed, 22 May 2002 10:23:51 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


Thanks for the answer. 

In that case, shouldn't the "expires" parameter in the Subscription-State
header in NOTIFY carry the same MUST strength as for Expires header in 200
OK response to SUBSCRIBE, instead of just a SHOULD (second last paragraph of
4.2.2 of draft-sip-events)? Section 4.2.4 'Subscriber NOTIFY Behavior' also
talks about the "expires" parameter with "If the Subscription-State header
also contains an "expires" parameter...", but what if it does not ? Can a
NOTIFY request which matches (according to 4.3.4) the SUBSCRIBE request
create a subscription and a new dialog if its Subscription-State does not
contain an "expires" parameter ?

Regards,
Ya-Ching Tan


Jonathan Rosenberg wrote:
| 
| There is an expires parameter in the Subscription-State header which
| conveys the expiration of the subscription. The decision was made not to
| use the Expires header for this purpose, since Expires refers to the
| message its carried in, and it is not the NOTIFY which is 
| expiring, but the subscription.
| 

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



From daemon@optimus.ietf.org  Wed May 22 07:20:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22665
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 07:20:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA14368
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 07:20:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12381;
	Wed, 22 May 2002 06:42:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12350
	for <sip@optimus.ietf.org>; Wed, 22 May 2002 06:42:40 -0400 (EDT)
Received: from gw-nl6.philips.com (gw-nl6.philips.com [212.153.235.103])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21198
	for <sip@ietf.org>; Wed, 22 May 2002 06:42:19 -0400 (EDT)
From: frank.derks@philips.com
Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24])
	by gw-nl6.philips.com (Postfix) with ESMTP id 4B88FA0CA5
	for <sip@ietf.org>; Wed, 22 May 2002 12:42:38 +0200 (MET DST)
Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) 
	by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA13467
	for <sip@ietf.org>; Wed, 22 May 2002 12:42:38 +0200 (MET DST)
Received: from ehv001soh.diamond.philips.com (e2soh01.diamond.philips.com [130.139.52.212]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id MAA17163
	for <sip@ietf.org>; Wed, 22 May 2002 12:42:37 +0200 (MET DST)
To: sip@ietf.org
Subject: Re: [Sip] Last Call: The Refer Method to Proposed Standard
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <OF95B53F2E.C3AA0417-ONC1256BC1.00368E6A@diamond.philips.com>
Date: Wed, 22 May 2002 12:41:04 +0200
X-MIMETrack: Serialize by Router on ehv001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at
 22/05/2002 12:43:37,
	Serialize complete at 22/05/2002 12:43:37
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_alternative 003AD12CC1256BC1_="
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

- Section 6.1, 2nd paragraph, contains a rather strange sentence

  "For example, if the URI is a SIP URI indicating an INVITE 
   should be generated ..."

  I guess that it should be:

  "For example, if the URI is a SIP URI indicating an INVITE 
   an INVITE should be generated ..."

- The use of colons after header names is not always consistent.
  E.g. in 6.3.1's first bullet item "Call-ID".

- Section 7.1, first paragraph, states:

  "The details of this flow indicate this ..."

  I guess it should state:

  "The details of this flow indicate that this ..."

  Furthermore, the example that follows is not in line with the
  text. The text states that there is no To: tag, but there is
  one in the example.

- Section 8.1 talks about INVITE URIs. I am not sure whether this
  type of URI (although I think I understand what is meant) is 
  defined anywhere.

 
Regards,

Frank


----- Original Message -----
From: "The IESG" <iesg-secretary@ietf.org>
To: <IETF-Announce:>
Cc: <sip@ietf.org>
Sent: Monday, May 20, 2002 12:59 PM
Subject: [Sip] Last Call: The Refer Method to Proposed Standard


>
> The IESG has received a request from the Session Initiation Protocol
> Working Group to consider publication of the following Internet-Drafts
> as Proposed Standards:
>
>  o The Refer Method
> <draft-ietf-sip-refer-04.txt>
>  o The Session Inititation Protocol (SIP)
> <draft-ietf-sip-replaces-02.txt>
>  o The Reason Header Field for the Session Initiation Protocol
> <draft-ietf-sip-reason-01.txt>
>  o Internet Media Types message/sipfrag
> <draft-sparks-sip-mimetypes-03.txt>
>  o SIP Extension for Registering Non-Adjacent Contacts
> <draft-willis-sip-path-06.txt>
>
>
> The IESG will also consider publication of Best Current Practices for
> Third Party Call Control in the Session Initiation Protocol
> <draft-ietf-sipping-3pcc-00.txt> as a BCP.
>
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002.
>
> Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt
> http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt
> http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 003AD12CC1256BC1_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2 face="Courier">- Section 6.1, 2nd paragraph, contains a rather strange sentence</font>
<br>
<br><font size=2 face="Courier">&nbsp; &quot;For example, if the URI is a SIP URI indicating an INVITE </font>
<br><font size=2 face="Courier">&nbsp; &nbsp;should be generated ...&quot;</font>
<br>
<br><font size=2 face="Courier">&nbsp; I guess that it should be:</font>
<br>
<br><font size=2 face="Courier">&nbsp; &quot;For example, if the URI is a SIP URI indicating an INVITE </font>
<br><font size=2 face="Courier">&nbsp; &nbsp;an INVITE should be generated ...&quot;</font>
<br>
<br><font size=2 face="Courier">- The use of colons after header names is not always consistent.</font>
<br><font size=2 face="Courier">&nbsp; E.g. in 6.3.1's first bullet item &quot;Call-ID&quot;.</font>
<br>
<br><font size=2 face="Courier">- Section 7.1, first paragraph, states:</font>
<br>
<br><font size=2 face="Courier">&nbsp; &quot;The details of this flow indicate this ...&quot;</font>
<br>
<br><font size=2 face="Courier">&nbsp; I guess it should state:</font>
<br>
<br><font size=2 face="Courier">&nbsp; &quot;The details of this flow indicate that this ...&quot;</font>
<br>
<br><font size=2 face="Courier">&nbsp; Furthermore, the example that follows is not in line with the</font>
<br><font size=2 face="Courier">&nbsp; text. The text states that there is no To: tag, but there is</font>
<br><font size=2 face="Courier">&nbsp; one in the example.</font>
<br>
<br><font size=2 face="Courier">- Section 8.1 talks about INVITE URIs. I am not sure whether this</font>
<br><font size=2 face="Courier">&nbsp; type of URI (although I think I understand what is meant) is </font>
<br><font size=2 face="Courier">&nbsp; defined anywhere.</font>
<br>
<br><font size=2 face="Courier">&nbsp;</font>
<br><font size=2 face="Courier">Regards,</font>
<br>
<br><font size=2 face="Courier">Frank</font>
<br>
<br>
<br><font size=2 face="Courier">----- Original Message -----<br>
From: &quot;The IESG&quot; &lt;iesg-secretary@ietf.org&gt;<br>
To: &lt;IETF-Announce:&gt;<br>
Cc: &lt;sip@ietf.org&gt;<br>
Sent: Monday, May 20, 2002 12:59 PM<br>
Subject: [Sip] Last Call: The Refer Method to Proposed Standard<br>
<br>
<br>
&gt;<br>
&gt; The IESG has received a request from the Session Initiation Protocol<br>
&gt; Working Group to consider publication of the following Internet-Drafts<br>
&gt; as Proposed Standards:<br>
&gt;<br>
&gt; &nbsp;o The Refer Method<br>
&gt; &lt;draft-ietf-sip-refer-04.txt&gt;<br>
&gt; &nbsp;o The Session Inititation Protocol (SIP)<br>
&gt; &lt;draft-ietf-sip-replaces-02.txt&gt;<br>
&gt; &nbsp;o The Reason Header Field for the Session Initiation Protocol<br>
&gt; &lt;draft-ietf-sip-reason-01.txt&gt;<br>
&gt; &nbsp;o Internet Media Types message/sipfrag<br>
&gt; &lt;draft-sparks-sip-mimetypes-03.txt&gt;<br>
&gt; &nbsp;o SIP Extension for Registering Non-Adjacent Contacts<br>
&gt; &lt;draft-willis-sip-path-06.txt&gt;<br>
&gt;<br>
&gt;<br>
&gt; The IESG will also consider publication of Best Current Practices for<br>
&gt; Third Party Call Control in the Session Initiation Protocol<br>
&gt; &lt;draft-ietf-sipping-3pcc-00.txt&gt; as a BCP.<br>
&gt;<br>
&gt;<br>
&gt; The IESG plans to make a decision in the next few weeks, and solicits<br>
&gt; final comments on this action. &nbsp;Please send any comments to the<br>
&gt; iesg@ietf.org or ietf@ietf.org mailing lists by June 3, 2002.<br>
&gt;<br>
&gt; Files can be obtained via<br>
http://www.ietf.org/internet-drafts/draft-ietf-sip-refer-04.txt<br>
&gt; http://www.ietf.org/internet-drafts/draft-ietf-sip-replaces-02.txt<br>
&gt; http://www.ietf.org/internet-drafts/draft-ietf-sip-reason-01.txt<br>
&gt; http://www.ietf.org/internet-drafts/draft-sparks-sip-mimetypes-03.txt<br>
&gt; http://www.ietf.org/internet-drafts/draft-willis-sip-path-06.txt<br>
&gt; http://www.ietf.org/internet-drafts/draft-ietf-sipping-3pcc-00.txt<br>
&gt;<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<br>
&gt; Use 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>
_______________________________________________<br>
Sip mailing list &nbsp;https://www1.ietf.org/mailman/listinfo/sip<br>
This list is for NEW development of the core SIP Protocol</font>
<br><font size=2 face="Courier">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>
<br>
<br>
--=_alternative 003AD12CC1256BC1_=--

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



From daemon@optimus.ietf.org  Wed May 22 07:49:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24609
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 07:49:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA16221
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 07:50:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14450;
	Wed, 22 May 2002 07:21:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14427
	for <sip@optimus.ietf.org>; Wed, 22 May 2002 07:21:35 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22859;
	Wed, 22 May 2002 07:21:13 -0400 (EDT)
Message-Id: <200205221121.HAA22859@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 22 May 2002 07:21:13 -0400
Subject: [Sip] I-D ACTION:draft-willis-sip-path-07.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: SIP Extension for Registering Non-Adjacent Contacts
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-path-07.txt
	Pages		: 18
	Date		: 21-May-02
	
The REGISTER function is used in a SIP system primarily to associate
a temporary contact address with an address-of-record.  This contact
is generally in the form of a URI, such as Contact:
<sip:alice@pc33.atlanta.com> and is generally dynamic and associated
with the IP address or hostname of the SIP UA.  The problem is that
network topology may have one or more SIP proxies between the UA and
the registrar, such that any request travelling from the user's home
network to the registered UA must traverse these proxies.  The
REGISTER method does not give us a mechanism to discover and record
this sequence of proxies in the registrar for future use.  This
document defines an extension header field, 'Path' which provides
such a mechanism

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-willis-sip-path-07.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@ns.ietf.org  Wed May 22 10:10:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03414
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 10:10:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA27067
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 10:11:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23225;
	Wed, 22 May 2002 09:27:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23194
	for <sip@ns.ietf.org>; Wed, 22 May 2002 09:27:47 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00942
	for <sip@ietf.org>; Wed, 22 May 2002 09:27:28 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g4MDQSX62294;
	Wed, 22 May 2002 08:26:28 -0500 (CDT)
Message-ID: <3CEB9C74.9050509@dynamicsoft.com>
Date: Wed, 22 May 2002 08:26:12 -0500
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: dean.willis@softarmor.com, jdrosen@dynamicsoft.com, hgs@cs.columbia.edu,
        mat@cisco.com, seancolson@yahoo.com, sip@ietf.org
Subject: Re: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED22@esebe013.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

aki.niemi@nokia.com wrote:
>>Aki says:

[snip]

>>It's called a B2BUA or "in network UA" -- it accepts the SIP message,
>>stores the content, and sends a new message (containing a pointer) on
>>towards the user. Like other B2BUA-ish things, this capability is
>>implicit in the current specification.
> 
> 
> Yes, the capability is there, but since the sender itself is always responsible for enforcing the 1300 byte size limitation of the MESSAGE request, this effectively negates any need for such a UA in the network.
> 
> I was saying that it would be nice if the actual enforcement of the size limit could be relaxed, so that it could also be up to such a store-and-forward UA in the network. However, having said that I can't think of a simple way to make this happen.
>  

You would still have the congestion control issue to the b2bua. We are 
adding new wording to say that if you know you are congestion-safe all 
the way, you can exceed the limit. If that device is under your control 
in such a way that you can ensure congestion-safe transports all the way 
to the b2bua, then you would be covered.

Thanks!

Ben.


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



From daemon@ns.ietf.org  Wed May 22 10:43:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05057
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 10:43:18 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA28947
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 10:43:37 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25555;
	Wed, 22 May 2002 09:59:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25524
	for <sip@ns.ietf.org>; Wed, 22 May 2002 09:59:07 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02732
	for <sip@ietf.org>; Wed, 22 May 2002 09:58:47 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MDwTL17424;
	Wed, 22 May 2002 15:58:29 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MDvfU29306;
	Wed, 22 May 2002 14:57:41 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <L1AJTS8H>; Wed, 22 May 2002 14:58:49 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7262@zwcwd00r.europe.nortel.com>
From: "Mark Watson"<mwatson@nortelnetworks.com>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Rohan Mahy'"
	 <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Wed, 22 May 2002 14:58:41 +0100
Importance: high
X-Priority: 1
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

All,

Can we have a *decision* asap as to whether the 'hint' uses
Asserted-Identity, or another header in another draft.

I do not mind which. If the latter I will publish an I-D describing it as
soon as we have a decision, assuming it is this week, since I'm away next
week.

If we do nothing, then I guess 3GPP will make up its own mind how to do
this, without supervision or advice from IETF, which I think would  be a bad
thing.

Regards...Mark


-----Original Message-----
From: Watson, Mark [MDN05:EP10:EXCH] 
Sent: 20 May 2002 12:08
To: 'Peterson, Jon'; 'Rohan Mahy'
Cc: sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?


The 'hint' was one of the three requirements that 3GPP communicated to us in
April. 
It is a separate requirement from the Network Asserted Identity itself, and
so is not addressed in the requirements draft, although I have been careful
to point this out, and to point out that it is a requirement nontheless, on
several occasions.
I believe we need the 'hint' in the same timeframe as the rest of the short
term work. 
Whether it is the same header/draft or a different header/draft is another
question on which I will only say that we'd better make up our minds pretty
quick.
...Mark 


> -----Original Message----- 
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> Sent: 19 May 2002 18:11 
> To: 'Rohan Mahy' 
> Cc: sip@ietf.org 
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> 
> 
> 
> My argument was not that the proposed hint won't work - just 
> that it isn't 
> necessary to solve the problem at hand. It might not be the 
> case that the 
> problems with the hint stop at the philosophical point you 
> mention below. 
> What I asked in my last mail was not whether or not we needed 
> a hint, but 
> rather whether or not we should table that question until we 
> resolve the 
> other questions at hand. I just don't want to spend the 
> cycles arguing about 
> the hint given our very aggressive timetable - frankly, I think that 
> reaching consensus on this hint matter might push back our 
> dates a bit. 
> Let's investigate this hint stuff in June, but for now just 
> figure out how a 
> Trust Domain can manage an asserted identity in a message. 
> 
> Jon Peterson 
> NeuStar, Inc. 
> 
> > -----Original Message----- 
> > From: Rohan Mahy [mailto:rohan@cisco.com] 
> > Sent: Sunday, May 19, 2002 8:29 AM 
> > To: Peterson, Jon 
> > Cc: sip@ietf.org 
> > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? 
> > 
> > 
> > Hi, 
> > 
> > The requirement for a hint is well understood, limited in 
> > scope, and well motivated in the draft.  Nobody has identified 
> > any technical reason why the hint won't work.   Your argument 
> > that allowing a hint weakens the strength of the language on 
> > ignoring Asserted-Identity from untrusted parties is purely 
> > philosophical in nature.  I don't buy your argument. 
> > 
> > thanks, 
> > -rohan 
> > 
> > 
> > ---- Original message ---- 
> > >Date: Fri, 17 May 2002 16:02:11 -0500 
> > >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > >To: "'sip@ietf.org'" <sip@ietf.org> 
> > > 
> > > 
> > >In the course of the discussion between Mark Watson, Cullen 
> > Jennings and 
> > >myself about the short-term identity work, we have returned a 
> > few times to 
> > >the question of the infamous hint. This hint is, of course, a 
> > way that a 
> > >user agent (one that is not a member of the Trust Domain in 
> > the short-term 
> > >network asserted identity space) can provide a 'hint' to the 
> > intermediary 
> > >that will generate an Asserted-Identity indicating which 
> > identity among 
> > >several possibilities should be asserted. 
> > > 
> > >The need for this arises particularly from the 3G space, in 
> > which the 
> > >authentication process takes place independently of SIP and 
> > does not carry 
> > >this sort of personal identity information. It also assumes 
> > that the 
> > >operators of the intermediary in question are aware of 
> > several legitimate 
> > >identities which the user can elect to assert. 
> > > 
> > >It has been proposed on the mailing list and elsewhere that the 
> > >Asserted-Identity header should be re-used by user agents 
> > outside the Trust 
> > >Domain to provide such a hint. I see a number of reasons for 
> > and against 
> > >using the Asserted-Identity for this purpose. For example, 
> > today, there is a 
> > >requirement that asserted-identities which are transmitted 
> > from untrusted 
> > >sources should not be used in any way - this would seem to 
> > weaken that 
> > >requirement. There is also possibly some behavior that still 
> > needs to be 
> > >specified (like how an intermediary would reject or otherwise 
> > handle a 
> > >request with an inappropriate hint) that might be impactful 
> > to our choice. 
> > > 
> > >For the time being, however, I would like to suggest that 
> > providing the hint 
> > >is outside the scope of the current deliverables (the 
> > asserted-identity 
> > >requirements and mechanism drafts), which need to be 
> > complete, as we 
> > >discussed in the interim meeting, by the end of this month. I 
> > believe that a 
> > >separate draft should propose the use of Asserted-Identity or 
> > any other 
> > >header for this hint (in whatever timeframe is appropriate 
> > for 3G's 
> > >requirements), but that we should not speak to this matter in 
> > the current 
> > >asserted-identity deliverables. There is, as I see it, no 
> > dependency on 
> > >defining this hint before we dictate how intermediaries will 
> > assert 
> > >identities. 
> > > 
> > >Any comments on this plan? 
> > > 
> > >Jon Peterson 
> > >NeuStar, Inc. 
> > > 
> > >_______________________________________________ 
> > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> > >This list is for NEW development of the core SIP 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 daemon@ns.ietf.org  Wed May 22 11:17:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08754
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 11:17:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA01331
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:18:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29025;
	Wed, 22 May 2002 10:45:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28997
	for <sip@ns.ietf.org>; Wed, 22 May 2002 10:45:47 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05202
	for <sip@ietf.org>; Wed, 22 May 2002 10:45:26 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4MEjFPI001625;
	Wed, 22 May 2002 07:45:15 -0700 (PDT)
Received: from OranLT ([161.44.238.34])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with ESMTP id ACY99404;
	Wed, 22 May 2002 07:45:25 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Rohan Mahy'" <rohan@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Wed, 22 May 2002 10:45:12 -0400
Organization: Cisco Systems
Message-ID: <005b01c2019f$476c8f80$22ee2ca1@OranLT>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <A3C2399B2FACD411A54200508BE39C74054F7262@zwcwd00r.europe.nortel.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I suggest we allow the hint to be placed in the asserted-identity rather
than in another header. A boundary proxy has to deal with a UA putting
in the header no matter what, if only to reject the request with an
error.

Once we have a full solution the issue of hints should go away as a side
effect of having the "authorization server" functionality that Jon
proposes. Better IMHO to have one obsolescent header to deal with rather
than two, as well as avoiding the concomitant verbiage describing the
combinatoric cases involving two headers.

Dave.

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of Mark Watson
> Sent: Wednesday, May 22, 2002 9:59 AM
> To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> Importance: High
> 
> 
> All,
> 
> Can we have a *decision* asap as to whether the 'hint' uses 
> Asserted-Identity, or another header in another draft.
> 
> I do not mind which. If the latter I will publish an I-D 
> describing it as soon as we have a decision, assuming it is 
> this week, since I'm away next week.
> 
> If we do nothing, then I guess 3GPP will make up its own mind 
> how to do this, without supervision or advice from IETF, 
> which I think would  be a bad thing.
> 
> Regards...Mark
> 
> 
> -----Original Message-----
> From: Watson, Mark [MDN05:EP10:EXCH] 
> Sent: 20 May 2002 12:08
> To: 'Peterson, Jon'; 'Rohan Mahy'
> Cc: sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> The 'hint' was one of the three requirements that 3GPP 
> communicated to us in April. 
> It is a separate requirement from the Network Asserted 
> Identity itself, and so is not addressed in the requirements 
> draft, although I have been careful to point this out, and to 
> point out that it is a requirement nontheless, on several 
> occasions. I believe we need the 'hint' in the same timeframe 
> as the rest of the short term work. 
> Whether it is the same header/draft or a different 
> header/draft is another question on which I will only say 
> that we'd better make up our minds pretty quick. ...Mark 
> 
> 
> > -----Original Message-----
> > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> > Sent: 19 May 2002 18:11 
> > To: 'Rohan Mahy' 
> > Cc: sip@ietf.org 
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > 
> > 
> > 
> > My argument was not that the proposed hint won't work - just
> > that it isn't 
> > necessary to solve the problem at hand. It might not be the 
> > case that the 
> > problems with the hint stop at the philosophical point you 
> > mention below. 
> > What I asked in my last mail was not whether or not we needed 
> > a hint, but 
> > rather whether or not we should table that question until we 
> > resolve the 
> > other questions at hand. I just don't want to spend the 
> > cycles arguing about 
> > the hint given our very aggressive timetable - frankly, I 
> think that 
> > reaching consensus on this hint matter might push back our 
> > dates a bit. 
> > Let's investigate this hint stuff in June, but for now just 
> > figure out how a 
> > Trust Domain can manage an asserted identity in a message. 
> > 
> > Jon Peterson
> > NeuStar, Inc. 
> > 
> > > -----Original Message-----
> > > From: Rohan Mahy [mailto:rohan@cisco.com] 
> > > Sent: Sunday, May 19, 2002 8:29 AM 
> > > To: Peterson, Jon 
> > > Cc: sip@ietf.org 
> > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? 
> > > 
> > > 
> > > Hi,
> > > 
> > > The requirement for a hint is well understood, limited in
> > > scope, and well motivated in the draft.  Nobody has identified 
> > > any technical reason why the hint won't work.   Your argument 
> > > that allowing a hint weakens the strength of the language on 
> > > ignoring Asserted-Identity from untrusted parties is purely 
> > > philosophical in nature.  I don't buy your argument. 
> > > 
> > > thanks,
> > > -rohan 
> > > 
> > > 
> > > ---- Original message ----
> > > >Date: Fri, 17 May 2002 16:02:11 -0500
> > > >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> > > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > > >To: "'sip@ietf.org'" <sip@ietf.org> 
> > > > 
> > > > 
> > > >In the course of the discussion between Mark Watson, Cullen
> > > Jennings and
> > > >myself about the short-term identity work, we have returned a
> > > few times to
> > > >the question of the infamous hint. This hint is, of course, a
> > > way that a
> > > >user agent (one that is not a member of the Trust Domain in
> > > the short-term
> > > >network asserted identity space) can provide a 'hint' to the
> > > intermediary
> > > >that will generate an Asserted-Identity indicating which
> > > identity among
> > > >several possibilities should be asserted.
> > > > 
> > > >The need for this arises particularly from the 3G space, in
> > > which the
> > > >authentication process takes place independently of SIP and
> > > does not carry
> > > >this sort of personal identity information. It also assumes
> > > that the
> > > >operators of the intermediary in question are aware of
> > > several legitimate
> > > >identities which the user can elect to assert.
> > > > 
> > > >It has been proposed on the mailing list and elsewhere that the
> > > >Asserted-Identity header should be re-used by user agents 
> > > outside the Trust
> > > >Domain to provide such a hint. I see a number of reasons for
> > > and against
> > > >using the Asserted-Identity for this purpose. For example,
> > > today, there is a
> > > >requirement that asserted-identities which are transmitted
> > > from untrusted
> > > >sources should not be used in any way - this would seem to
> > > weaken that
> > > >requirement. There is also possibly some behavior that still
> > > needs to be
> > > >specified (like how an intermediary would reject or otherwise
> > > handle a
> > > >request with an inappropriate hint) that might be impactful
> > > to our choice.
> > > > 
> > > >For the time being, however, I would like to suggest that
> > > providing the hint
> > > >is outside the scope of the current deliverables (the
> > > asserted-identity
> > > >requirements and mechanism drafts), which need to be
> > > complete, as we
> > > >discussed in the interim meeting, by the end of this month. I
> > > believe that a
> > > >separate draft should propose the use of Asserted-Identity or
> > > any other
> > > >header for this hint (in whatever timeframe is appropriate
> > > for 3G's
> > > >requirements), but that we should not speak to this matter in
> > > the current
> > > >asserted-identity deliverables. There is, as I see it, no
> > > dependency on
> > > >defining this hint before we dictate how intermediaries will
> > > assert
> > > >identities.
> > > > 
> > > >Any comments on this plan?
> > > > 
> > > >Jon Peterson
> > > >NeuStar, Inc. 
> > > > 
> > > >_______________________________________________
> > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> > > >This list is for NEW development of the core SIP 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 daemon@ns.ietf.org  Wed May 22 11:22:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09490
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 11:22:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA01478
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:22:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29429;
	Wed, 22 May 2002 10:52:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29325
	for <sip@ns.ietf.org>; Wed, 22 May 2002 10:52:28 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05472
	for <sip@ietf.org>; Wed, 22 May 2002 10:52:07 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 17AXTP-0004SV-00; Wed, 22 May 2002 17:52:19 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15595.45219.118919.381999@harjus.eng.song.fi>
Date: Wed, 22 May 2002 17:52:19 +0300
To: "Mark Watson"<mwatson@nortelnetworks.com>
Cc: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Rohan Mahy'"
	 <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
In-Reply-To: <A3C2399B2FACD411A54200508BE39C74054F7262@zwcwd00r.europe.nortel.com>
References: <A3C2399B2FACD411A54200508BE39C74054F7262@zwcwd00r.europe.nortel.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Mark Watson writes:

 > Can we have a *decision* asap as to whether the 'hint' uses
 > Asserted-Identity, or another header in another draft.

i don't care what the "hint" header is called, as long as it is not
"hint".  the term "hint" is not good for this purpose, because it is not
something the network can override.  the network can only check it and
then either accept it or reject the call.

if Asserted-Identity is not ok for the majority, then my suggestion is
"Really-From".  it should be used only in case the from header is
anonymous.  otherwise the sip uri in the from header is used.

-- 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 daemon@ns.ietf.org  Wed May 22 11:27:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10577
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 11:27:59 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA02034
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:28:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29468;
	Wed, 22 May 2002 10:52:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29328
	for <sip@ns.ietf.org>; Wed, 22 May 2002 10:52:28 -0400 (EDT)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05468
	for <sip@ietf.org>; Wed, 22 May 2002 10:51:56 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4MEmqKf021663;
	Wed, 22 May 2002 10:48:52 -0400 (EDT)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <LJW811ZY>; Wed, 22 May 2002 10:51:29 -0400
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F36B4782@DYN-TX-EXCH-001.dynamicsoft.com>
From: Andrew Allen <AAllen@dynamicsoft.com>
To: "'David R. Oran'" <oran@cisco.com>,
        "'Mark Watson'"
	 <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'"
	 <jon.peterson@neustar.biz>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Wed, 22 May 2002 10:51:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


I agree with Dave. Lets put the hint in the asserted-identity. Lets not have
two redundant headers that need to be transferred over the Radio interface
unnecessarily.

Andrew

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: Wednesday, May 22, 2002 9:45 AM
> To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> I suggest we allow the hint to be placed in the 
> asserted-identity rather
> than in another header. A boundary proxy has to deal with a UA putting
> in the header no matter what, if only to reject the request with an
> error.
> 
> Once we have a full solution the issue of hints should go 
> away as a side
> effect of having the "authorization server" functionality that Jon
> proposes. Better IMHO to have one obsolescent header to deal 
> with rather
> than two, as well as avoiding the concomitant verbiage describing the
> combinatoric cases involving two headers.
> 
> Dave.
> 
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> > Behalf Of Mark Watson
> > Sent: Wednesday, May 22, 2002 9:59 AM
> > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > Importance: High
> > 
> > 
> > All,
> > 
> > Can we have a *decision* asap as to whether the 'hint' uses 
> > Asserted-Identity, or another header in another draft.
> > 
> > I do not mind which. If the latter I will publish an I-D 
> > describing it as soon as we have a decision, assuming it is 
> > this week, since I'm away next week.
> > 
> > If we do nothing, then I guess 3GPP will make up its own mind 
> > how to do this, without supervision or advice from IETF, 
> > which I think would  be a bad thing.
> > 
> > Regards...Mark
> > 
> > 
> > -----Original Message-----
> > From: Watson, Mark [MDN05:EP10:EXCH] 
> > Sent: 20 May 2002 12:08
> > To: 'Peterson, Jon'; 'Rohan Mahy'
> > Cc: sip@ietf.org
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > 
> > 
> > The 'hint' was one of the three requirements that 3GPP 
> > communicated to us in April. 
> > It is a separate requirement from the Network Asserted 
> > Identity itself, and so is not addressed in the requirements 
> > draft, although I have been careful to point this out, and to 
> > point out that it is a requirement nontheless, on several 
> > occasions. I believe we need the 'hint' in the same timeframe 
> > as the rest of the short term work. 
> > Whether it is the same header/draft or a different 
> > header/draft is another question on which I will only say 
> > that we'd better make up our minds pretty quick. ...Mark 
> > 
> > 
> > > -----Original Message-----
> > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> > > Sent: 19 May 2002 18:11 
> > > To: 'Rohan Mahy' 
> > > Cc: sip@ietf.org 
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > > 
> > > 
> > > 
> > > My argument was not that the proposed hint won't work - just
> > > that it isn't 
> > > necessary to solve the problem at hand. It might not be the 
> > > case that the 
> > > problems with the hint stop at the philosophical point you 
> > > mention below. 
> > > What I asked in my last mail was not whether or not we needed 
> > > a hint, but 
> > > rather whether or not we should table that question until we 
> > > resolve the 
> > > other questions at hand. I just don't want to spend the 
> > > cycles arguing about 
> > > the hint given our very aggressive timetable - frankly, I 
> > think that 
> > > reaching consensus on this hint matter might push back our 
> > > dates a bit. 
> > > Let's investigate this hint stuff in June, but for now just 
> > > figure out how a 
> > > Trust Domain can manage an asserted identity in a message. 
> > > 
> > > Jon Peterson
> > > NeuStar, Inc. 
> > > 
> > > > -----Original Message-----
> > > > From: Rohan Mahy [mailto:rohan@cisco.com] 
> > > > Sent: Sunday, May 19, 2002 8:29 AM 
> > > > To: Peterson, Jon 
> > > > Cc: sip@ietf.org 
> > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? 
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > The requirement for a hint is well understood, limited in
> > > > scope, and well motivated in the draft.  Nobody has identified 
> > > > any technical reason why the hint won't work.   Your argument 
> > > > that allowing a hint weakens the strength of the language on 
> > > > ignoring Asserted-Identity from untrusted parties is purely 
> > > > philosophical in nature.  I don't buy your argument. 
> > > > 
> > > > thanks,
> > > > -rohan 
> > > > 
> > > > 
> > > > ---- Original message ----
> > > > >Date: Fri, 17 May 2002 16:02:11 -0500
> > > > >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> > > > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > > > >To: "'sip@ietf.org'" <sip@ietf.org> 
> > > > > 
> > > > > 
> > > > >In the course of the discussion between Mark Watson, Cullen
> > > > Jennings and
> > > > >myself about the short-term identity work, we have returned a
> > > > few times to
> > > > >the question of the infamous hint. This hint is, of course, a
> > > > way that a
> > > > >user agent (one that is not a member of the Trust Domain in
> > > > the short-term
> > > > >network asserted identity space) can provide a 'hint' to the
> > > > intermediary
> > > > >that will generate an Asserted-Identity indicating which
> > > > identity among
> > > > >several possibilities should be asserted.
> > > > > 
> > > > >The need for this arises particularly from the 3G space, in
> > > > which the
> > > > >authentication process takes place independently of SIP and
> > > > does not carry
> > > > >this sort of personal identity information. It also assumes
> > > > that the
> > > > >operators of the intermediary in question are aware of
> > > > several legitimate
> > > > >identities which the user can elect to assert.
> > > > > 
> > > > >It has been proposed on the mailing list and elsewhere that the
> > > > >Asserted-Identity header should be re-used by user agents 
> > > > outside the Trust
> > > > >Domain to provide such a hint. I see a number of reasons for
> > > > and against
> > > > >using the Asserted-Identity for this purpose. For example,
> > > > today, there is a
> > > > >requirement that asserted-identities which are transmitted
> > > > from untrusted
> > > > >sources should not be used in any way - this would seem to
> > > > weaken that
> > > > >requirement. There is also possibly some behavior that still
> > > > needs to be
> > > > >specified (like how an intermediary would reject or otherwise
> > > > handle a
> > > > >request with an inappropriate hint) that might be impactful
> > > > to our choice.
> > > > > 
> > > > >For the time being, however, I would like to suggest that
> > > > providing the hint
> > > > >is outside the scope of the current deliverables (the
> > > > asserted-identity
> > > > >requirements and mechanism drafts), which need to be
> > > > complete, as we
> > > > >discussed in the interim meeting, by the end of this month. I
> > > > believe that a
> > > > >separate draft should propose the use of Asserted-Identity or
> > > > any other
> > > > >header for this hint (in whatever timeframe is appropriate
> > > > for 3G's
> > > > >requirements), but that we should not speak to this matter in
> > > > the current
> > > > >asserted-identity deliverables. There is, as I see it, no
> > > > dependency on
> > > > >defining this hint before we dictate how intermediaries will
> > > > assert
> > > > >identities.
> > > > > 
> > > > >Any comments on this plan?
> > > > > 
> > > > >Jon Peterson
> > > > >NeuStar, Inc. 
> > > > > 
> > > > >_______________________________________________
> > > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> > > > >This list is for NEW development of the core SIP 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 daemon@ns.ietf.org  Wed May 22 11:48:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13319
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 11:48:27 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA03645
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 11:48:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01201;
	Wed, 22 May 2002 11:16:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01169
	for <sip@ns.ietf.org>; Wed, 22 May 2002 11:16:38 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08474
	for <sip@ietf.org>; Wed, 22 May 2002 11:16:01 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MFFgB02254;
	Wed, 22 May 2002 17:15:42 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MFEtU29450;
	Wed, 22 May 2002 16:14:55 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <L1AJTW0H>; Wed, 22 May 2002 16:16:02 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7263@zwcwd00r.europe.nortel.com>
From: "Mark Watson"<mwatson@nortelnetworks.com>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>,
        Cullen Jennings
	 <fluffy@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and hist
	ory requirements
Date: Wed, 22 May 2002 16:15:59 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C201A3.338ADED2"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C201A3.338ADED2
Content-Type: text/plain;
	charset="iso-8859-1"

I don't think this header overlaps with Request History.

This header contains information identifying the NETWORK that a call is FROM
(or rather has passed through) whereas Request History records information
about changes in the Request-URI which indicates the USER that a call is TO.

I don't think the Request-URI would ever contain the identity of the
vistited network, so this information would not be captured by Request
History.

Regards...Mark

> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com]
> Sent: 22 May 2002 09:00
> To: Cullen Jennings
> Cc: sip@ietf.org
> Subject: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and
> history requirements
> 
> 
> Hi Cullen:
> 
> I am aware that this P- header may be part of the history. 
> However, as you know,
> the history is still in requirements phase, whereas 3GPP 
> Release 5 needs a 
> solution by June timeframe.
> 
> Miguel
> 
> Cullen Jennings wrote:
> > 
> > It seems to me that the mechanism that meets the 
> requirements of the history
> > requirements (draft-watson-sipping-req-history-01.txt) 
> would also solve this
> > problem. Do we want two things to do the same thing?
> > 
> > Cullen
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
> mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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_01C201A3.338ADED2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Sip] Re: draft-garcia-sip-visited-network-id-01.txt and =
history requirements</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I don't think this header overlaps with Request =
History.</FONT>
</P>

<P><FONT SIZE=3D2>This header contains information identifying the =
NETWORK that a call is FROM (or rather has passed through) whereas =
Request History records information about changes in the Request-URI =
which indicates the USER that a call is TO.</FONT></P>

<P><FONT SIZE=3D2>I don't think the Request-URI would ever contain the =
identity of the vistited network, so this information would not be =
captured by Request History.</FONT></P>

<P><FONT SIZE=3D2>Regards...Mark</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Miguel A. Garcia [<A =
HREF=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@eric=
sson.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 22 May 2002 09:00</FONT>
<BR><FONT SIZE=3D2>&gt; To: Cullen Jennings</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [Sip] Re: =
draft-garcia-sip-visited-network-id-01.txt and</FONT>
<BR><FONT SIZE=3D2>&gt; history requirements</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Cullen:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am aware that this P- header may be part of =
the history. </FONT>
<BR><FONT SIZE=3D2>&gt; However, as you know,</FONT>
<BR><FONT SIZE=3D2>&gt; the history is still in requirements phase, =
whereas 3GPP </FONT>
<BR><FONT SIZE=3D2>&gt; Release 5 needs a </FONT>
<BR><FONT SIZE=3D2>&gt; solution by June timeframe.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Miguel</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Cullen Jennings wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; It seems to me that the mechanism that =
meets the </FONT>
<BR><FONT SIZE=3D2>&gt; requirements of the history</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirements =
(draft-watson-sipping-req-history-01.txt) </FONT>
<BR><FONT SIZE=3D2>&gt; would also solve this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problem. Do we want two things to do the =
same thing?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cullen</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- </FONT>
<BR><FONT SIZE=3D2>&gt; Miguel-Angel =
Garcia&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Oy LM Ericsson =
AB</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Jorvas, Finland</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"mailto:Miguel.A.Garcia@ericsson.com">mailto:Miguel.A.Garcia@eric=
sson.com</A>&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp; +358 9 299 =
3553</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"mailto:Miguel.A.Garcia@piuha.net">mailto:Miguel.A.Garcia@piuha.n=
et</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mobile: +358 40 =
5140002</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; This list is for NEW development of the core =
SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; Use sipping@ietf.org for new developments on =
the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C201A3.338ADED2--

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



From daemon@ns.ietf.org  Wed May 22 14:20:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23239
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 14:20:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA13237
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 14:20:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11256;
	Wed, 22 May 2002 13:48:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11193
	for <sip@ns.ietf.org>; Wed, 22 May 2002 13:48:00 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21638
	for <sip@ietf.org>; Wed, 22 May 2002 13:47:38 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MHkWd24220;
	Wed, 22 May 2002 12:46:32 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        <hgs@cs.columbia.edu>
Date: Wed, 22 May 2002 12:46:03 -0500
Message-ID: <004801c201b8$8b4f1060$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


We started working group last call of the sip-dhcpv6 draft on May 2.
There has been no negative veedback that I'm aware of, so let's call
WGLC complete and request IETF Last Call.

http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt


--
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 daemon@ns.ietf.org  Wed May 22 14:24:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23493
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 14:24:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA13498
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 14:24:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11267;
	Wed, 22 May 2002 13:48:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA11195
	for <sip@ns.ietf.org>; Wed, 22 May 2002 13:48:00 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21639
	for <sip@ietf.org>; Wed, 22 May 2002 13:47:38 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MHkXd24223;
	Wed, 22 May 2002 12:46:33 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <aki.niemi@nokia.com>, <jdrosen@dynamicsoft.com>
Cc: <bcampbell@dynamicsoft.com>, <hgs@cs.columbia.edu>, <mat@cisco.com>,
        <seancolson@yahoo.com>, <sip@ietf.org>
Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)
Date: Wed, 22 May 2002 12:46:03 -0500
Message-ID: <004901c201b8$8bdb98f0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-reply-to: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90FED22@esebe013.NOE.Nokia.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


> Yes, the capability is there, but since the sender itself is
> always responsible for enforcing the 1300 byte size 
> limitation of the MESSAGE request, this effectively negates 
> any need for such a UA in the network.
> 
> I was saying that it would be nice if the actual enforcement
> of the size limit could be relaxed, so that it could also be 
> up to such a store-and-forward UA in the network. However, 
> having said that I can't think of a simple way to make this happen.


Ah. I think you're right. I'm not a fan of the 3261 wording on size
being blaneltly applied to message -- I think it far more reasonable to
make the forwarding deision on a per-sip-HOP basis, where the decision
maker has a reasonable understanding of the dynamics of the next hop,
and if we find a hop that has a smaller-than-message MTU and doesn't
support congestion control we reject and say "send smaller" . . .
There's much to be learned from Path-MTU discovery in TCP.

--
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 daemon@ns.ietf.org  Wed May 22 15:26:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26796
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 15:26:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA17579
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 15:26:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16151;
	Wed, 22 May 2002 15:00:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA15666
	for <sip@ns.ietf.org>; Wed, 22 May 2002 14:54:33 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25136;
	Wed, 22 May 2002 14:54:11 -0400 (EDT)
Message-Id: <200205221854.OAA25136@ietf.org>
To: IETF-Announce: ;
Cc: sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Wed, 22 May 2002 14:54:11 -0400
Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol 
Working Group to consider DHCPv6 Options for SIP Servers 
<draft-ietf-sip-dhcpv6-00.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 any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt





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



From daemon@ns.ietf.org  Wed May 22 15:53:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28102
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 15:53:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA19285
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 15:53:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18491;
	Wed, 22 May 2002 15:33:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17475
	for <sip@ns.ietf.org>; Wed, 22 May 2002 15:21:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26566;
	Wed, 22 May 2002 15:20:57 -0400 (EDT)
Message-Id: <200205221920.PAA26566@ietf.org>
To: IETF-Announce: ;
Cc: sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Reply-to: iesg@ietf.org
Date: Wed, 22 May 2002 15:20:57 -0400
Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol 
Working Group to consider DHCPv6 Options for SIP Servers 
<draft-ietf-sip-dhcpv6-00.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 any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt





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



From daemon@ns.ietf.org  Wed May 22 17:16:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01525
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 17:16:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA24011
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 17:16:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21971;
	Wed, 22 May 2002 16:54:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21940
	for <sip@ns.ietf.org>; Wed, 22 May 2002 16:54:31 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29928
	for <sip@ietf.org>; Wed, 22 May 2002 16:54:10 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MKrcd25497;
	Wed, 22 May 2002 15:53:38 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Cc: <brian.rosen@marconi.com>, <rohan@cisco.com>, <jo@ipdialog.com>,
        <mankin@isi.edu>
Date: Wed, 22 May 2002 15:53:08 -0500
Message-ID: <006401c201d2$adefa980$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


There have been only "nit" comments on the last few revs of this draft,
and I believe they're all accounted for.

I think we can close the Expert Review of this individual informational
draft.


Shall we proceed?

Allison, HOW shall we proceed? Remember, this is a "P-header" . . .

Do we have internet-drafts process as a typical individual
informational, or does this go through iesg-secretary?

--
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 daemon@ns.ietf.org  Wed May 22 17:20:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02066
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 17:20:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA24173
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 17:20:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21773;
	Wed, 22 May 2002 16:49:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21742
	for <sip@ns.ietf.org>; Wed, 22 May 2002 16:49:43 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29731;
	Wed, 22 May 2002 16:49:22 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4MKnBd25467;
	Wed, 22 May 2002 15:49:11 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <internet-drafts@ietf.org>
Date: Wed, 22 May 2002 15:48:41 -0500
Message-ID: <006301c201d2$0edc8c50$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Revised: draft-willis-sip-svcrtdisco to -05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


We have (I believe) incorporated all comments received during working
group Expert Review into draft-willis-sip-svcrtdisco.

The new version is posted at:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-05.htm
l
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-05.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-svcrtdisco-05.xml

--
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 daemon@ns.ietf.org  Wed May 22 17:54:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03795
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 17:54:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA25947
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 17:54:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25275;
	Wed, 22 May 2002 17:34:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25243
	for <sip@ns.ietf.org>; Wed, 22 May 2002 17:34:39 -0400 (EDT)
Received: from crash.dfw.dynamicsoft.com ([63.110.3.64])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02982
	for <sip@ietf.org>; Wed, 22 May 2002 17:34:18 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4MLahV23788;
	Wed, 22 May 2002 16:36:46 -0500
Subject: Re: [Sip] Last Call: The Refer Method to Proposed Standard
From: Robert Sparks <rsparks@dynamicsoft.com>
To: frank.derks@philips.com
Cc: sip@ietf.org
In-Reply-To: <OF95B53F2E.C3AA0417-ONC1256BC1.00368E6A@diamond.philips.com>
References: <OF95B53F2E.C3AA0417-ONC1256BC1.00368E6A@diamond.philips.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 22 May 2002 16:23:24 -0500
Message-Id: <1022102607.4632.26.camel@dhcp150.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

On Wed, 2002-05-22 at 05:41, frank.derks@philips.com wrote:
> 
> - Section 6.1, 2nd paragraph, contains a rather strange sentence 
> 
>   "For example, if the URI is a SIP URI indicating an INVITE 
>    should be generated ..." 
> 
>   I guess that it should be: 
> 
>   "For example, if the URI is a SIP URI indicating an INVITE 
>    an INVITE should be generated ..." 
No, try
 "For example, if the URI is a SIP URI that indicates an INVITE
  should be generated".

See below
> 
> - The use of colons after header names is not always consistent. 
>   E.g. in 6.3.1's first bullet item "Call-ID". 
will fix
> 
> - Section 7.1, first paragraph, states: 
> 
>   "The details of this flow indicate this ..." 
> 
>   I guess it should state: 
> 
>   "The details of this flow indicate that this ..." 
correct. will add "that"

> 
>   Furthermore, the example that follows is not in line with the 
>   text. The text states that there is no To: tag, but there is 
>   one in the example. 
It states there is no To: tag in the REFER request (and there isn't).
I think you are seeing the To: tags in the subsequent messages?

> 
> - Section 8.1 talks about INVITE URIs. I am not sure whether this 
>   type of URI (although I think I understand what is meant) is 
>   defined anywhere. 
draft-rfc2543bis-09 captures this in its discussion of SIP URIs.

An SIP INVITE URI is one which either has no ;method= URI parameter
(defaulting to INVITE) or explicitly states ;method=INVITE.
Alternatives might look like
sip:rsparks@dynamicsoft.com;method=SUBSCRIBE

>   
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 daemon@ns.ietf.org  Wed May 22 19:40:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08168
	for <sip-archive@odin.ietf.org>; Wed, 22 May 2002 19:40:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA00727
	for sip-archive@odin.ietf.org; Wed, 22 May 2002 19:40:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27083;
	Wed, 22 May 2002 18:21:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA27052
	for <sip@ns.ietf.org>; Wed, 22 May 2002 18:21:55 -0400 (EDT)
Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05023
	for <sip@ietf.org>; Wed, 22 May 2002 18:21:33 -0400 (EDT)
Received: from minotaur (mankin@localhost)
	by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g4MMLpJ12643;
	Wed, 22 May 2002 18:21:51 -0400
Message-Id: <200205222221.g4MMLpJ12643@minotaur.nge.isi.edu>
To: "Dean Willis" <dwillis@dynamicsoft.com>
cc: sip@ietf.org, brian.rosen@marconi.com, rohan@cisco.com, jo@ipdialog.com,
        mankin@isi.edu
Reply-To: mankin@isi.edu
Subject: Re: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05? 
In-reply-to: Your message of Wed, 22 May 2002 15:53:08 -0500.
             <006401c201d2$adefa980$1d036e3f@TXDWILLIS2> 
Mime-Version: 1.0 (generated by tm-edit 1.7)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 22 May 2002 18:21:51 -0400
From: Allison Mankin <mankin@isi.edu>
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Dean,

HOW you should proceed with a P-Header Informational:


My view is that you send mail to the transport ADs
saying expert review concluded the i-d was publishable
as an Info, and could TSV please get it on the IESG
agenda.  We can encode this in sipchange a little more
specifically (now it says you write to IESG on this).

Sometimes the draft will come to IESG and Expert Review
from the RFC Editor, but in this case, we don't need it
to come from RFC-Ed.

Allison

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



From daemon@optimus.ietf.org  Thu May 23 00:41:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17801
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 00:41:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA13628
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 00:41:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12606;
	Thu, 23 May 2002 00:16:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA12577
	for <sip@optimus.ietf.org>; Thu, 23 May 2002 00:16:02 -0400 (EDT)
Received: from esuims01.esamsungumit.com (mail.esamsungumit.com [203.122.29.230])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17353
	for <sip@ietf.org>; Thu, 23 May 2002 00:15:40 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Thu, 23 May 2002 09:46:02 +0530
Message-ID: <89CFEE6120A0224EA07781892EC0B48B7EC56C@esuims01.esamsungumit.com>
Thread-Topic: load generation by a UA.
Thread-Index: AcICEIwRXZNKAWDGTyiW8UGoj/UtlA==
From: "ShavinderPal Singh" <ShavinderPal.Singh@esamsungumit.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA12578
Subject: [Sip] load generation by a UA.
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Hi,

Is there a possibility by which I can use a SIP UA to generate a more
than 50 calls simultaneously? ( Or some other way)
I need it for testing purposes. All we need is some way to initiate 50
calls per second, just to flood a SIP proxy.
If this is possible, I would also need some way that these 50 calls
generated should be accepted at the other end by a "called party UA". so
that the "called UA" send 2xx's and these 50 calls are established also.

So, please suggest. If any body has done it, please tell me how can I
achieve this?

Thanks & Regards
s

Ph.: 091-124-6383474 (e 250)



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



From daemon@optimus.ietf.org  Thu May 23 05:23:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01540
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 05:23:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA05201
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 05:24:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04159;
	Thu, 23 May 2002 05:03:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA04113
	for <sip@optimus.ietf.org>; Thu, 23 May 2002 05:03:31 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01036
	for <sip@ietf.org>; Thu, 23 May 2002 05:03:12 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA11516;
	Thu, 23 May 2002 11:03:05 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id LAA02205;
	Thu, 23 May 2002 11:03:18 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LL4YTNA8>; Thu, 23 May 2002 11:03:15 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DD1@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'Dean Willis'" <dwillis@dynamicsoft.com>, sip@ietf.org
Cc: brian.rosen@marconi.com, rohan@cisco.com, jo@ipdialog.com, mankin@isi.edu
Subject: RE: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-0
	5?
Date: Thu, 23 May 2002 11:03:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

I hope this is not too late...

Comments :

- 6.1 "If the UA refreshes the registration, the stored value of the
P-Service-Route is updated according to the P-Service-Route header field of
the latest 200 OK response".  What happens if the re-registration gets
negative response, or if the registration state expires? Should the UA clear
the stored service route or should it still keeps the one from the latest
200 OK response?

- 6.3 3rd paragraph "A REGISTER operation performing a Fetching Bindings
SHOULD return the same value of P-Service-Route as returned in the
corresponding previous REGISTER response for the address-of-record in
question". I thought the whole idea is to avoid storing lookup tables in the
home network (point 3 of Section 2). I would assume that the registrar
generates a service route for the registering UA (be it a real registration
or just a fetch) dynamically, based on its knowledge about the topology of
the home network at that moment. So it cannot guarantee that the
P-Service-Route calculated now has the same value as the one returned in the
previous REGISTER response.

Nits:

- 6.1 "The UA performs a register as usual . The register response..." =>
"The UA registers an address-of-record as usual. The REGISTER response..."

- In the examples, 200 OK to REGISTER should have To tags according to RFC
3261.


Regards,
Ya-Ching

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



From daemon@optimus.ietf.org  Thu May 23 09:32:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09512
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 09:32:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA18413
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 09:32:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16768;
	Thu, 23 May 2002 09:06:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16737
	for <sip@optimus.ietf.org>; Thu, 23 May 2002 09:06:00 -0400 (EDT)
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08250
	for <sip@ietf.org>; Thu, 23 May 2002 09:05:31 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x3.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4ND7JT26370
	for <sip@ietf.org>; Thu, 23 May 2002 16:07:19 +0300 (EET DST)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b0a7c55b5ac158f2113b@esvir01nok.ntc.nokia.com>;
 Thu, 23 May 2002 16:05:44 +0300
Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 23 May 2002 16:05:42 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 23 May 2002 16:05:42 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 23 May 2002 16:05:41 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791E3@esebe019.NOE.Nokia.com>
Thread-Topic: Comments on Path-07
Thread-Index: AcICWorYCc6lCwQTT0yxT6D6RlRZYA==
To: <sip@ietf.org>
Cc: <dean.willis@softarmor.com>
X-OriginalArrivalTime: 23 May 2002 13:05:42.0322 (UTC) FILETIME=[8B107920:01C2025A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA16738
Subject: [Sip] Comments on Path-07
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

In section 4.2, it is mentioned that if a Proxy requires that the registrar supports the path extension, it inserts a Require header, should the proxy remove the supported header in that case? it is kinda redundant.

Section 4.4 assumes that the home proxy and registrar are always co-located. What about when they are not (not talking about 3GPP for now).

So in your diagram, P3 is actually the home proxy for UA2. Should there be some text talking about how P3 should behave when it receives a request? It contact the registrar, gets the path headers converts them to route and finds itself in the top-most route-header.

The same issue was brought up about record-route and route headers. A proxy should remove the first route header or (if its not smart enough to recognise its own route, should just send it to itself).

Also in this section, it does not mention anything about the first route being a strict-route and that the R-URI needs to be re-written yet again.

In section 5, (this is a little too picky) in your examples, the display names in the to-header and from-header have '@'. This is not allowed. You need to place quotes around them,  or better still, change them to something meaningful.

There are also few spelling mistakes and nits, do you want those?

Regards,
Hisham


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



From daemon@optimus.ietf.org  Thu May 23 11:10:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13877
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 11:10:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA25677
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 11:10:44 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23114;
	Thu, 23 May 2002 10:46:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23083
	for <sip@optimus.ietf.org>; Thu, 23 May 2002 10:46:34 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12808
	for <sip@ietf.org>; Thu, 23 May 2002 10:46:14 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4NEk0d31431;
	Thu, 23 May 2002 09:46:00 -0500
Message-ID: <006a01c20268$95f71ed0$133fed0c@C1893415A>
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: "Tan Ya-Ching  ICM N PG U ID A 1" <Ya-Ching.Tan@icn.siemens.de>,
        <sip@ietf.org>
Cc: <brian.rosen@marconi.com>, <rohan@cisco.com>, <jo@ipdialog.com>,
        <mankin@isi.edu>, "Bernhard Honeisen" <bernhard.honeisen@nokia.com>
References: <5B4D0C5BA65ECA46969C1419122317E6E74DD1@mchh161e>
Subject: Re: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05?
Date: Thu, 23 May 2002 09:46:12 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Thanks, will incorporate.

I believe the procedure we're going to use is that I'll send the revised
draft to the transport ADs and ask them to get it onto the IESG agenda.
This probably points to  a slight need for clarification in the SIP
Change Process draft.

So, one more rev before IESG. I'll incorporate any reasonable feedback
received by 1400 USCST today.

--
Dean


----- Original Message -----
From: "Tan Ya-Ching ICM N PG U ID A 1" <Ya-Ching.Tan@icn.siemens.de>
To: "'Dean Willis'" <dwillis@dynamicsoft.com>; <sip@ietf.org>
Cc: <brian.rosen@marconi.com>; <rohan@cisco.com>; <jo@ipdialog.com>;
<mankin@isi.edu>
Sent: Thursday, May 23, 2002 4:03 AM
Subject: RE: [Sip] Close of Expert Review on
draft-willis-sip-svcrtdisco-05?


> Hi,
>
> I hope this is not too late...
>
> Comments :
>
> - 6.1 "If the UA refreshes the registration, the stored value of the
> P-Service-Route is updated according to the P-Service-Route header
field of
> the latest 200 OK response".  What happens if the re-registration gets
> negative response, or if the registration state expires? Should the UA
clear
> the stored service route or should it still keeps the one from the
latest
> 200 OK response?
>
> - 6.3 3rd paragraph "A REGISTER operation performing a Fetching
Bindings
> SHOULD return the same value of P-Service-Route as returned in the
> corresponding previous REGISTER response for the address-of-record in
> question". I thought the whole idea is to avoid storing lookup tables
in the
> home network (point 3 of Section 2). I would assume that the registrar
> generates a service route for the registering UA (be it a real
registration
> or just a fetch) dynamically, based on its knowledge about the
topology of
> the home network at that moment. So it cannot guarantee that the
> P-Service-Route calculated now has the same value as the one returned
in the
> previous REGISTER response.
>
> Nits:
>
> - 6.1 "The UA performs a register as usual . The register response..."
=>
> "The UA registers an address-of-record as usual. The REGISTER
response..."
>
> - In the examples, 200 OK to REGISTER should have To tags according to
RFC
> 3261.
>
>
> Regards,
> Ya-Ching
>
>


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



From daemon@optimus.ietf.org  Thu May 23 11:47:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15340
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 11:47:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA28696
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 11:47:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26550;
	Thu, 23 May 2002 11:21:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA26521
	for <sip@optimus.ietf.org>; Thu, 23 May 2002 11:21:35 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14365
	for <sip@ietf.org>; Thu, 23 May 2002 11:21:13 -0400 (EDT)
Received: from C1893415A (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with SMTP id g4NFKtd31742;
	Thu, 23 May 2002 10:20:55 -0500
Message-ID: <00e901c2026d$76c92620$133fed0c@C1893415A>
From: "Dean Willis" <dean.willis@softarmor.com>
To: <hisham.khartabil@nokia.com>, <sip@ietf.org>
References: <2038BCC78B1AD641891A0D1AE133DBB77791E3@esebe019.NOE.Nokia.com>
Date: Thu, 23 May 2002 10:21:08 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: Comments on Path-07
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hisham wrote:
> In section 4.2, it is mentioned that if a Proxy requires that the
registrar supports the path extension, it inserts a Require header,
should the proxy remove the supported header in that case? it is kinda
redundant.

No, because the registrar has to decide with to do if the extension is
required by a proxy but not supported by the UA. The two obvious options
are "reject" and "accept", although there might also be an "accept and
notify somebody externally".

This is addressed in 4.3, Procedures at the Registrar:

"If a registrar receives a REGISTER request containing a Path header
field and there is no indication of support for the extension in the UA
(via A Supported header field), the registrar must rely on local policy
in determining how to treat this request. The recommended policy is for
the registrar to reject the request with a 420 "Bad Extension" response
indicating the Path extension. This approach allows the UA to detect
that an intermediate proxy has innapropriatelty added a Path header
field. However, the Path mechanism should technically work in the
absence of UA support (at some compromise to security), so some
registrars may choose to support the extension in the absence of a
Supported header field value in the request."

> Section 4.4 assumes that the home proxy and registrar are always
co-located. What about when they are not (not talking about 3GPP for
now).

> So in your diagram, P3 is actually the home proxy for UA2. Should
there be some text talking about how P3 should behave when it receives a
request? It contact the registrar, gets the path headers converts them
to route and finds itself in the top-most route-header.

>
> The same issue was brought up about record-route and route headers. A
proxy should remove the first route header or (if its not smart enough
to recognise its own route, should just send it to itself).

I could put in a clarification that, if not co-located with the
registrar, the home proxy apply local topology knowledge to construct a
return route from the stored Path vector.

>
> Also in this section, it does not mention anything about the first
route being a strict-route and that the R-URI needs to be re-written yet
again.

Huh?

>
> In section 5, (this is a little too picky) in your examples, the
display names in the to-header and from-header have '@'. This is not
allowed. You need to place quotes around them,  or better still, change
them to something meaningful.

I assume you mean section 4? Good catch.

> There are also few spelling mistakes and nits, do you want those?

Yes. That's why I asked for feedback and proofreading on the list.
That's why we went through six versions during list discussion and
working group last call. That's why we have a seperate IETF Last Call,
which has now been going on for over a week.

So please post any corrections you think are needed. Be explicit! The
same applies to any document under working group review -- the authors
will be appreciative, and our work will be of better quality, if all of
you folks in the working group take the initiative to provide feedback.
Of course, the authors are free to disagree with suggestions and discuss
further.

Thanks!

--
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 daemon@ns.ietf.org  Thu May 23 12:49:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17804
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 12:49:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA04356
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 12:50:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02296;
	Thu, 23 May 2002 12:19:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02265
	for <sip@ns.ietf.org>; Thu, 23 May 2002 12:19:51 -0400 (EDT)
Received: from zctfs063.europe.nortel.com (zctfs063.nortelnetworks.com [47.164.128.120])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16820
	for <sip@ietf.org>; Thu, 23 May 2002 12:19:26 -0400 (EDT)
Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92])
	by zctfs063.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NGI5l17979;
	Thu, 23 May 2002 18:18:05 +0200 (MEST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187])
	by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NGHFW14021;
	Thu, 23 May 2002 17:17:15 +0100 (BST)
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19)
	id <L1AJ46FL>; Thu, 23 May 2002 17:18:28 +0100
Message-ID: <A3C2399B2FACD411A54200508BE39C74054F7274@zwcwd00r.europe.nortel.com>
From: "Mark Watson"<mwatson@nortelnetworks.com>
To: "'Andrew Allen'" <AAllen@dynamicsoft.com>,
        "'David R. Oran'"
	 <oran@cisco.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Thu, 23 May 2002 17:18:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20274.F267C406"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

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

In the absence of further comment, can I make a *proposal* that we stick
with Asserted-Identity for the hint and for the NAI itself, and that both
are described in Cullen's draft ?

Can we take this as AGREED if there are no comments by cob tomorrow ?
(Guidance sought from chairs on this second question).

Updated requirements draft to be submitted first thing tomorrow.

Regards...Mark

> -----Original Message-----
> From: Andrew Allen [mailto:AAllen@dynamicsoft.com]
> Sent: 22 May 2002 15:51
> To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon';
> 'Rohan Mahy'; sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> 
> I agree with Dave. Lets put the hint in the 
> asserted-identity. Lets not have
> two redundant headers that need to be transferred over the 
> Radio interface
> unnecessarily.
> 
> Andrew
> 
> > -----Original Message-----
> > From: David R. Oran [mailto:oran@cisco.com]
> > Sent: Wednesday, May 22, 2002 9:45 AM
> > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > 
> > 
> > I suggest we allow the hint to be placed in the 
> > asserted-identity rather
> > than in another header. A boundary proxy has to deal with a 
> UA putting
> > in the header no matter what, if only to reject the request with an
> > error.
> > 
> > Once we have a full solution the issue of hints should go 
> > away as a side
> > effect of having the "authorization server" functionality that Jon
> > proposes. Better IMHO to have one obsolescent header to deal 
> > with rather
> > than two, as well as avoiding the concomitant verbiage 
> describing the
> > combinatoric cases involving two headers.
> > 
> > Dave.
> > 
> > > -----Original Message-----
> > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> > > Behalf Of Mark Watson
> > > Sent: Wednesday, May 22, 2002 9:59 AM
> > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > > Importance: High
> > > 
> > > 
> > > All,
> > > 
> > > Can we have a *decision* asap as to whether the 'hint' uses 
> > > Asserted-Identity, or another header in another draft.
> > > 
> > > I do not mind which. If the latter I will publish an I-D 
> > > describing it as soon as we have a decision, assuming it is 
> > > this week, since I'm away next week.
> > > 
> > > If we do nothing, then I guess 3GPP will make up its own mind 
> > > how to do this, without supervision or advice from IETF, 
> > > which I think would  be a bad thing.
> > > 
> > > Regards...Mark
> > > 
> > > 
> > > -----Original Message-----
> > > From: Watson, Mark [MDN05:EP10:EXCH] 
> > > Sent: 20 May 2002 12:08
> > > To: 'Peterson, Jon'; 'Rohan Mahy'
> > > Cc: sip@ietf.org
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > > 
> > > 
> > > The 'hint' was one of the three requirements that 3GPP 
> > > communicated to us in April. 
> > > It is a separate requirement from the Network Asserted 
> > > Identity itself, and so is not addressed in the requirements 
> > > draft, although I have been careful to point this out, and to 
> > > point out that it is a requirement nontheless, on several 
> > > occasions. I believe we need the 'hint' in the same timeframe 
> > > as the rest of the short term work. 
> > > Whether it is the same header/draft or a different 
> > > header/draft is another question on which I will only say 
> > > that we'd better make up our minds pretty quick. ...Mark 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> > > > Sent: 19 May 2002 18:11 
> > > > To: 'Rohan Mahy' 
> > > > Cc: sip@ietf.org 
> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > > > 
> > > > 
> > > > 
> > > > My argument was not that the proposed hint won't work - just
> > > > that it isn't 
> > > > necessary to solve the problem at hand. It might not be the 
> > > > case that the 
> > > > problems with the hint stop at the philosophical point you 
> > > > mention below. 
> > > > What I asked in my last mail was not whether or not we needed 
> > > > a hint, but 
> > > > rather whether or not we should table that question until we 
> > > > resolve the 
> > > > other questions at hand. I just don't want to spend the 
> > > > cycles arguing about 
> > > > the hint given our very aggressive timetable - frankly, I 
> > > think that 
> > > > reaching consensus on this hint matter might push back our 
> > > > dates a bit. 
> > > > Let's investigate this hint stuff in June, but for now just 
> > > > figure out how a 
> > > > Trust Domain can manage an asserted identity in a message. 
> > > > 
> > > > Jon Peterson
> > > > NeuStar, Inc. 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Rohan Mahy [mailto:rohan@cisco.com] 
> > > > > Sent: Sunday, May 19, 2002 8:29 AM 
> > > > > To: Peterson, Jon 
> > > > > Cc: sip@ietf.org 
> > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? 
> > > > > 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > The requirement for a hint is well understood, limited in
> > > > > scope, and well motivated in the draft.  Nobody has 
> identified 
> > > > > any technical reason why the hint won't work.   Your argument 
> > > > > that allowing a hint weakens the strength of the language on 
> > > > > ignoring Asserted-Identity from untrusted parties is purely 
> > > > > philosophical in nature.  I don't buy your argument. 
> > > > > 
> > > > > thanks,
> > > > > -rohan 
> > > > > 
> > > > > 
> > > > > ---- Original message ----
> > > > > >Date: Fri, 17 May 2002 16:02:11 -0500
> > > > > >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > > > > >To: "'sip@ietf.org'" <sip@ietf.org> 
> > > > > > 
> > > > > > 
> > > > > >In the course of the discussion between Mark Watson, Cullen
> > > > > Jennings and
> > > > > >myself about the short-term identity work, we have returned a
> > > > > few times to
> > > > > >the question of the infamous hint. This hint is, of course, a
> > > > > way that a
> > > > > >user agent (one that is not a member of the Trust Domain in
> > > > > the short-term
> > > > > >network asserted identity space) can provide a 'hint' to the
> > > > > intermediary
> > > > > >that will generate an Asserted-Identity indicating which
> > > > > identity among
> > > > > >several possibilities should be asserted.
> > > > > > 
> > > > > >The need for this arises particularly from the 3G space, in
> > > > > which the
> > > > > >authentication process takes place independently of SIP and
> > > > > does not carry
> > > > > >this sort of personal identity information. It also assumes
> > > > > that the
> > > > > >operators of the intermediary in question are aware of
> > > > > several legitimate
> > > > > >identities which the user can elect to assert.
> > > > > > 
> > > > > >It has been proposed on the mailing list and 
> elsewhere that the
> > > > > >Asserted-Identity header should be re-used by user agents 
> > > > > outside the Trust
> > > > > >Domain to provide such a hint. I see a number of reasons for
> > > > > and against
> > > > > >using the Asserted-Identity for this purpose. For example,
> > > > > today, there is a
> > > > > >requirement that asserted-identities which are transmitted
> > > > > from untrusted
> > > > > >sources should not be used in any way - this would seem to
> > > > > weaken that
> > > > > >requirement. There is also possibly some behavior that still
> > > > > needs to be
> > > > > >specified (like how an intermediary would reject or otherwise
> > > > > handle a
> > > > > >request with an inappropriate hint) that might be impactful
> > > > > to our choice.
> > > > > > 
> > > > > >For the time being, however, I would like to suggest that
> > > > > providing the hint
> > > > > >is outside the scope of the current deliverables (the
> > > > > asserted-identity
> > > > > >requirements and mechanism drafts), which need to be
> > > > > complete, as we
> > > > > >discussed in the interim meeting, by the end of this month. I
> > > > > believe that a
> > > > > >separate draft should propose the use of Asserted-Identity or
> > > > > any other
> > > > > >header for this hint (in whatever timeframe is appropriate
> > > > > for 3G's
> > > > > >requirements), but that we should not speak to this matter in
> > > > > the current
> > > > > >asserted-identity deliverables. There is, as I see it, no
> > > > > dependency on
> > > > > >defining this hint before we dictate how intermediaries will
> > > > > assert
> > > > > >identities.
> > > > > > 
> > > > > >Any comments on this plan?
> > > > > > 
> > > > > >Jon Peterson
> > > > > >NeuStar, Inc. 
> > > > > > 
> > > > > >_______________________________________________
> > > > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> > > > > >This list is for NEW development of the core SIP 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
> > 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: [Sip] Asserted-Identity: How to 'hint'?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>In the absence of further comment, can I make a =
*proposal* that we stick with Asserted-Identity for the hint and for =
the NAI itself, and that both are described in Cullen's draft =
?</FONT></P>

<P><FONT SIZE=3D2>Can we take this as AGREED if there are no comments =
by cob tomorrow ? (Guidance sought from chairs on this second =
question).</FONT></P>

<P><FONT SIZE=3D2>Updated requirements draft to be submitted first =
thing tomorrow.</FONT>
</P>

<P><FONT SIZE=3D2>Regards...Mark</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Andrew Allen [<A =
HREF=3D"mailto:AAllen@dynamicsoft.com">mailto:AAllen@dynamicsoft.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 22 May 2002 15:51</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'David R. Oran'; Watson, Mark =
[MDN05:EP10:EXCH]; 'Peterson, Jon';</FONT>
<BR><FONT SIZE=3D2>&gt; 'Rohan Mahy'; sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [Sip] Asserted-Identity: How to =
'hint'?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I agree with Dave. Lets put the hint in the =
</FONT>
<BR><FONT SIZE=3D2>&gt; asserted-identity. Lets not have</FONT>
<BR><FONT SIZE=3D2>&gt; two redundant headers that need to be =
transferred over the </FONT>
<BR><FONT SIZE=3D2>&gt; Radio interface</FONT>
<BR><FONT SIZE=3D2>&gt; unnecessarily.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Andrew</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: David R. Oran [<A =
HREF=3D"mailto:oran@cisco.com">mailto:oran@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, May 22, 2002 9:45 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan =
Mahy'; sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: [Sip] Asserted-Identity: How =
to 'hint'?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I suggest we allow the hint to be placed =
in the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; asserted-identity rather</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; than in another header. A boundary proxy =
has to deal with a </FONT>
<BR><FONT SIZE=3D2>&gt; UA putting</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the header no matter what, if only to =
reject the request with an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; error.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Once we have a full solution the issue of =
hints should go </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; away as a side</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; effect of having the &quot;authorization =
server&quot; functionality that Jon</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proposes. Better IMHO to have one =
obsolescent header to deal </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; with rather</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; than two, as well as avoiding the =
concomitant verbiage </FONT>
<BR><FONT SIZE=3D2>&gt; describing the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; combinatoric cases involving two =
headers.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dave.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: sip-admin@ietf.org [<A =
HREF=3D"mailto:sip-admin@ietf.org">mailto:sip-admin@ietf.org</A>] On =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Behalf Of Mark Watson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Wednesday, May 22, 2002 9:59 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: 'Peterson, Jon'; 'Rohan Mahy'; =
sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: [Sip] Asserted-Identity: =
How to 'hint'?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Importance: High</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Can we have a *decision* asap as to =
whether the 'hint' uses </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Asserted-Identity, or another header =
in another draft.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I do not mind which. If the latter I =
will publish an I-D </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; describing it as soon as we have a =
decision, assuming it is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; this week, since I'm away next =
week.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If we do nothing, then I guess 3GPP =
will make up its own mind </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; how to do this, without supervision =
or advice from IETF, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; which I think would&nbsp; be a bad =
thing.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Regards...Mark</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Watson, Mark [MDN05:EP10:EXCH] =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: 20 May 2002 12:08</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: 'Peterson, Jon'; 'Rohan =
Mahy'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: sip@ietf.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: [Sip] Asserted-Identity: =
How to 'hint'?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The 'hint' was one of the three =
requirements that 3GPP </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; communicated to us in April. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; It is a separate requirement from the =
Network Asserted </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Identity itself, and so is not =
addressed in the requirements </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; draft, although I have been careful =
to point this out, and to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; point out that it is a requirement =
nontheless, on several </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; occasions. I believe we need the =
'hint' in the same timeframe </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; as the rest of the short term work. =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Whether it is the same header/draft =
or a different </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; header/draft is another question on =
which I will only say </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that we'd better make up our minds =
pretty quick. ...Mark </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; From: Peterson, Jon [<A =
HREF=3D"mailto:jon.peterson@neustar.biz">mailto:jon.peterson@neustar.biz=
</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sent: 19 May 2002 18:11 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; To: 'Rohan Mahy' </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Cc: sip@ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Subject: RE: [Sip] =
Asserted-Identity: How to 'hint'? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; My argument was not that the =
proposed hint won't work - just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; that it isn't </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; necessary to solve the problem =
at hand. It might not be the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; case that the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; problems with the hint stop at =
the philosophical point you </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; mention below. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; What I asked in my last mail was =
not whether or not we needed </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a hint, but </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; rather whether or not we should =
table that question until we </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; resolve the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; other questions at hand. I just =
don't want to spend the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; cycles arguing about </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; the hint given our very =
aggressive timetable - frankly, I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; think that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; reaching consensus on this hint =
matter might push back our </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; dates a bit. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Let's investigate this hint =
stuff in June, but for now just </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; figure out how a </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Trust Domain can manage an =
asserted identity in a message. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Jon Peterson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; NeuStar, Inc. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; From: Rohan Mahy [<A =
HREF=3D"mailto:rohan@cisco.com">mailto:rohan@cisco.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Sent: Sunday, May 19, 2002 =
8:29 AM </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; To: Peterson, Jon </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Cc: sip@ietf.org </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Subject: Re: [Sip] =
Asserted-Identity: How to 'hint'? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; The requirement for a hint =
is well understood, limited in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; scope, and well motivated =
in the draft.&nbsp; Nobody has </FONT>
<BR><FONT SIZE=3D2>&gt; identified </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; any technical reason why =
the hint won't work.&nbsp;&nbsp; Your argument </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; that allowing a hint =
weakens the strength of the language on </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; ignoring Asserted-Identity =
from untrusted parties is purely </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; philosophical in =
nature.&nbsp; I don't buy your argument. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; -rohan </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; ---- Original message =
----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Date: Fri, 17 May 2002 =
16:02:11 -0500</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;From: &quot;Peterson, =
Jon&quot; &lt;jon.peterson@neustar.biz&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Subject: [Sip] =
Asserted-Identity: How to 'hint'?&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;To: =
&quot;'sip@ietf.org'&quot; &lt;sip@ietf.org&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;In the course of the =
discussion between Mark Watson, Cullen</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; Jennings and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;myself about the =
short-term identity work, we have returned a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; few times to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;the question of the =
infamous hint. This hint is, of course, a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; way that a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;user agent (one that is =
not a member of the Trust Domain in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; the short-term</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;network asserted =
identity space) can provide a 'hint' to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; intermediary</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;that will generate an =
Asserted-Identity indicating which</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; identity among</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;several possibilities =
should be asserted.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;The need for this =
arises particularly from the 3G space, in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; which the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;authentication process =
takes place independently of SIP and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; does not carry</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;this sort of personal =
identity information. It also assumes</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;operators of the =
intermediary in question are aware of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; several legitimate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;identities which the =
user can elect to assert.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;It has been proposed on =
the mailing list and </FONT>
<BR><FONT SIZE=3D2>&gt; elsewhere that the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Asserted-Identity =
header should be re-used by user agents </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; outside the Trust</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Domain to provide such =
a hint. I see a number of reasons for</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; and against</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;using the =
Asserted-Identity for this purpose. For example,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; today, there is a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;requirement that =
asserted-identities which are transmitted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; from untrusted</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;sources should not be =
used in any way - this would seem to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; weaken that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;requirement. There is =
also possibly some behavior that still</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; needs to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;specified (like how an =
intermediary would reject or otherwise</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; handle a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;request with an =
inappropriate hint) that might be impactful</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; to our choice.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;For the time being, =
however, I would like to suggest that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; providing the hint</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;is outside the scope of =
the current deliverables (the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; asserted-identity</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;requirements and =
mechanism drafts), which need to be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; complete, as we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;discussed in the =
interim meeting, by the end of this month. I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; believe that a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;separate draft should =
propose the use of Asserted-Identity or</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; any other</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;header for this hint =
(in whatever timeframe is appropriate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; for 3G's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;requirements), but that =
we should not speak to this matter in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; the current</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;asserted-identity =
deliverables. There is, as I see it, no</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; dependency on</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;defining this hint =
before we dictate how intermediaries will</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; assert</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;identities.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Any comments on this =
plan?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Jon Peterson</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;NeuStar, Inc. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; =
&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Sip mailing list&nbsp; =
<A HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A> =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;This list is for NEW =
development of the core SIP Protocol </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Use =
sip-implementors@cs.columbia.edu for questions on </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; current sip </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; &gt;Use sipping@ietf.org =
for new developments on the application </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; of sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A> =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; This list is for NEW development =
of the core SIP Protocol </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Use =
sip-implementors@cs.columbia.edu for questions on </FONT>
<BR><FONT SIZE=3D2>&gt; current sip </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Use sipping@ietf.org for new =
developments on the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; application of sip </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; This list is for NEW development of =
the core SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Use sip-implementors@cs.columbia.edu =
for questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Use sipping@ietf.org for new =
developments on the </FONT>
<BR><FONT SIZE=3D2>&gt; application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sip mailing list&nbsp; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/sip" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/sip</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This list is for NEW development of the =
core SIP Protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Use sip-implementors@cs.columbia.edu for =
questions on current sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Use sipping@ietf.org for new developments =
on the application of sip</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C20274.F267C406--

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



From daemon@ns.ietf.org  Thu May 23 14:19:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21614
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 14:19:26 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA09902
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 14:19:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08248;
	Thu, 23 May 2002 13:52:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08174
	for <sip@ns.ietf.org>; Thu, 23 May 2002 13:52:32 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20284;
	Thu, 23 May 2002 13:52:09 -0400 (EDT)
Message-Id: <200205231752.NAA20284@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>,
        sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Date: Thu, 23 May 2002 13:52:09 -0400
Subject: [Sip] Document Action: HTTP Digest Authentication Using AKA to
 Informational
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org



The IESG has approved the Internet-Draft 'HTTP Digest Authentication
Using AKA' <draft-ietf-sip-digest-aka-03.txt> as an Informational RFC.
This document is the product of the Session Initiation Protocol Working
Group.  The IESG contact persons are Allison Mankin and Scott Bradner.

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



From daemon@ns.ietf.org  Thu May 23 15:41:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24073
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 15:41:08 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA14073
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 15:41:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12550;
	Thu, 23 May 2002 15:13:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA12519
	for <sip@ns.ietf.org>; Thu, 23 May 2002 15:13:32 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23538
	for <sip@ietf.org>; Thu, 23 May 2002 15:13:11 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NJCZd00734;
	Thu, 23 May 2002 14:12:35 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Andrew Allen'" <AAllen@dynamicsoft.com>,
        "'David R. Oran'" <oran@cisco.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Rohan Mahy'" <rohan@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Thu, 23 May 2002 14:12:04 -0500
Message-ID: <006e01c2028d$b9e4a950$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <A3C2399B2FACD411A54200508BE39C74054F7274@zwcwd00r.europe.nortel.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Mark asked:
-------
In the absence of further comment, can I make a *proposal* that we stick
with Asserted-Identity for the hint and for the NAI itself, and that
both are described in Cullen's draft ?
Can we take this as AGREED if there are no comments by cob tomorrow ?
(Guidance sought from chairs on this second question).
Updated requirements draft to be submitted first thing tomorrow. 
--------

I support your proposal and AGREE with the closing plan.

In other words, an asserted-identity with nothing to back up the
assertion is just a statement of preference . . .

--
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 daemon@ns.ietf.org  Thu May 23 17:47:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28599
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 17:47:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA21228
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 17:47:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20034;
	Thu, 23 May 2002 17:21:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20003
	for <sip@ns.ietf.org>; Thu, 23 May 2002 17:21:16 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27781
	for <sip@ietf.org>; Thu, 23 May 2002 17:20:55 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NLJnd01468;
	Thu, 23 May 2002 16:19:50 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Tan Ya-Ching  ICM N PG U ID A 1'" <Ya-Ching.Tan@icn.siemens.de>,
        <sip@ietf.org>
Cc: <brian.rosen@marconi.com>, <rohan@cisco.com>, <jo@ipdialog.com>,
        <mankin@isi.edu>
Subject: RE: [Sip] Close of Expert Review on draft-willis-sip-svcrtdisco-05?
Date: Thu, 23 May 2002 16:19:17 -0500
Message-ID: <007b01c2029f$80aa3850$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <5B4D0C5BA65ECA46969C1419122317E6E74DD1@mchh161e>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Ya-Ching wrote:
> - 6.1 "If the UA refreshes the registration, the stored value 
> of the P-Service-Route is updated according to the 
> P-Service-Route header field of the latest 200 OK response".  
> What happens if the re-registration gets negative response, 
> or if the registration state expires? Should the UA clear the 
> stored service route or should it still keeps the one from 
> the latest 200 OK response?

I suspect that the UA clears the stored route in a negative response
case. It's kind of an open question what to do in the event of an
expiration. We can add some text to this point.

> 
> - 6.3 3rd paragraph "A REGISTER operation performing a 
> Fetching Bindings SHOULD return the same value of 
> P-Service-Route as returned in the corresponding previous 
> REGISTER response for the address-of-record in question". I 
> thought the whole idea is to avoid storing lookup tables in 
> the home network (point 3 of Section 2). I would assume that 
> the registrar generates a service route for the registering 
> UA (be it a real registration or just a fetch) dynamically, 
> based on its knowledge about the topology of the home network 
> at that moment. So it cannot guarantee that the 
> P-Service-Route calculated now has the same value as the one 
> returned in the previous REGISTER response.

That's a really good point. A lot depends on the manner in which the
P-Service-Route is constructed. It may in some cases be constructed from
Path data. So I'd say that the registrar returns the "current" service
route, whatever that is. I will so annotate.

> 
> Nits:
> 
> - 6.1 "The UA performs a register as usual . The register 
> response..." => "The UA registers an address-of-record as 
> usual. The REGISTER response..."

Yep.

> - In the examples, 200 OK to REGISTER should have To tags 
> according to RFC 3261.

Yep. Of course, 3261 is inconsistent in its use of To tags. I think the
whole tagging/branchid thing was a bad class of ideas, but I promised
not to suggest we deprecate forking any more. . .
 
Thanks for the feedback. It looks like one more rev . . .

--
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 daemon@ns.ietf.org  Thu May 23 18:34:31 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29603
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 18:34:31 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA23708
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 18:34:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22559;
	Thu, 23 May 2002 18:11:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22527
	for <sip@ns.ietf.org>; Thu, 23 May 2002 18:11:12 -0400 (EDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29103
	for <sip@ietf.org>; Thu, 23 May 2002 18:10:51 -0400 (EDT)
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NMAq812703
	for <sip@ietf.org>; Thu, 23 May 2002 17:10:52 -0500 (CDT)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KLRZPD5Z>; Thu, 23 May 2002 15:10:30 -0700
Message-ID: <2F1FC1DEA077D5119FAD00508BCFD6D202AF8B64@zsc3c030.us.nortel.com>
From: "Mo Zonoun"<mzonoun@nortelnetworks.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Thu, 23 May 2002 15:11:02 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C202A6.B9B610FE"
Subject: [Sip] (no subject)
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

------_=_NextPart_001_01C202A6.B9B610FE
Content-Type: text/plain

Unsubscribe  qpMQ mzonoun@nortelnetworks.com

------_=_NextPart_001_01C202A6.B9B610FE
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE></TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Unsubscribe</FONT>&nbsp;<FONT SIZE=2 FACE="Courier New"> qpMQ mzonoun@nortelnetworks.com</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C202A6.B9B610FE--

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



From daemon@ns.ietf.org  Thu May 23 19:49:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00836
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 19:49:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA26269
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 19:49:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25338;
	Thu, 23 May 2002 19:26:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25299
	for <sip@ns.ietf.org>; Thu, 23 May 2002 19:26:24 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00331
	for <sip@ietf.org>; Thu, 23 May 2002 19:26:02 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NNPXd02231;
	Thu, 23 May 2002 18:25:33 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, <jo@ipdialog.com>, <brian.rosen@marconi.com>,
        "Miguel Garcia" <Miguel.A.Garcia@ericsson.com>
Date: Thu, 23 May 2002 18:25:01 -0500
Message-ID: <008a01c202b1$10a12b60$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Poll: expert review of draft-garcia-sip-visited-network-id
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


As you may recall, we're providing expert review of
draft-garcia-sip-visited-network-id.

What's the feeling here? 

I THINK we have a general consensus that this work does not conflict
with anything.

Do we have a consensus that this is  draft is "good enough" to work as
an informational P-header?

Or do we reject it, or require further consideration?

Inquiring minds want to know . . .

--
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 daemon@ns.ietf.org  Thu May 23 19:51:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00893
	for <sip-archive@odin.ietf.org>; Thu, 23 May 2002 19:51:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA26317
	for sip-archive@odin.ietf.org; Thu, 23 May 2002 19:52:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25363;
	Thu, 23 May 2002 19:26:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA25307
	for <sip@ns.ietf.org>; Thu, 23 May 2002 19:26:25 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00336
	for <sip@ietf.org>; Thu, 23 May 2002 19:26:04 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4NNPYd02234;
	Thu, 23 May 2002 18:25:34 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        "Miguel Garcia" <Miguel.A.Garcia@ericsson.com>
Date: Thu, 23 May 2002 18:25:01 -0500
Message-ID: <008b01c202b1$10dfbb00$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Poll -- expert review of draft-garcia-sip-called-party-id
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


So team, what's the conclusion, if any, on
draft-garcia-sip-called-party-id?

Do we have a consensus for, consensus against, or require further
consideration?


--
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 daemon@optimus.ietf.org  Fri May 24 03:08:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19065
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 03:08:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA22826
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 03:08:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21856;
	Fri, 24 May 2002 02:50:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA21826
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 02:50:29 -0400 (EDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18858
	for <sip@ietf.org>; Fri, 24 May 2002 02:50:08 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4O6opk15212
	for <sip@ietf.org>; Fri, 24 May 2002 09:50:51 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b0e4b211eac158f23075@esvir03nok.nokia.com>;
 Fri, 24 May 2002 09:50:28 +0300
Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 24 May 2002 09:50:28 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 24 May 2002 09:50:28 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 24 May 2002 09:50:27 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB77791E6@esebe019.NOE.Nokia.com>
Thread-Topic: Comments on Path-07
Thread-Index: AcICbXGCpwSgLe+tSTqEUKFN7HOCYAAflTkg
To: <dean.willis@softarmor.com>, <sip@ietf.org>
X-OriginalArrivalTime: 24 May 2002 06:50:28.0237 (UTC) FILETIME=[4A097BD0:01C202EF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA21827
Subject: [Sip] RE: Comments on Path-07
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit



> -----Original Message-----
> From: ext Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Thursday, May 23, 2002 6:21 PM
> To: Khartabil Hisham (NMP/Helsinki); sip@ietf.org
> Subject: Re: Comments on Path-07
> 
> 
> Hisham wrote:
> > Also in this section, it does not mention anything about the first
> route being a strict-route and that the R-URI needs to be 
> re-written yet
> again.
> 
> Huh?
> 

Ok, I missed paragraph in section 4.3

"Note that the inserted Path header field values conform to the syntax
   of a Route element as defined in [1].  As suggested therein, such
   values MUST include the loose-routing indicator parameter ";lr" for
   full compliance with [1]"

Perhaps Section 4.2 is more appropriate for this (or in both sections).

> > There are also few spelling mistakes and nits, do you want those?
> 
> Yes. That's why I asked for feedback and proofreading on the list.
> That's why we went through six versions during list discussion and
> working group last call. That's why we have a seperate IETF Last Call,
> which has now been going on for over a week.
> 
> So please post any corrections you think are needed. Be explicit! The
> same applies to any document under working group review -- the authors
> will be appreciative, and our work will be of better quality, 
> if all of
> you folks in the working group take the initiative to provide 
> feedback.
> Of course, the authors are free to disagree with suggestions 
> and discuss
> further.

Ok then. Here are a few:

- Section 1 first sentence "p roxies" should be "proxies"

- Section 1 second paragraph 
"Likewise, all requests between REGISTRAR and UAa
   must also traverse P1, P2, and P3 before reaching UA."

should be

"Likewise, all requests between REGISTRAR and UA1
                                                ^
   must also traverse P1, P2, and P3 before reaching UA1."
                                                       ^
- Section 1 last paragraph, second last line "to to"

- Section 3 just above table 3

"Support for the Path header field may be indicated by a UA by
   including the option-tag "path" in a Supported header field."

Should that be a "MAY"?

- Section 4.4 last paragraph last line "poilicy" should be "policy"

That's all.

Regards,
Hisham


> 
> Thanks!
> 
> --
> 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 daemon@optimus.ietf.org  Fri May 24 03:24:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19240
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 03:24:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA23134
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 03:24:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22932;
	Fri, 24 May 2002 03:13:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22896
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 03:13:04 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19137
	for <sip@ietf.org>; Fri, 24 May 2002 03:12:43 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4O7CMuF024375;
	Fri, 24 May 2002 00:12:22 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACZ51096;
	Fri, 24 May 2002 00:12:44 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Miguel Garcia" <Miguel.A.Garcia@ericsson.com>, <sip@ietf.org>
Date: Fri, 24 May 2002 00:13:16 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCEEELCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <008b01c202b1$10dfbb00$1d036e3f@TXDWILLIS2>
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-garcia-sip-called-party-id and history
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I see this draft as dealing with the issue of a proxy retargeting
sip:user1-business@example.com to sip:user1@192.0.2.4

As a proposed change, how would you feel about changing the syntax from
P-Called-Party-ID to something like

P-History: sip:user1-business@example.com
or
P-History:
sip:user1-business@example.com;reason=SIP;cause=302;text="registrar
retargeted"

I understand that 3G wishes to resolve this by June, however, I think that
if we wanted to, we could do a P-History just as fast as a
P-Called-Party-ID. The existence of a non compatible Called-Party will
complicate getting History done. If the consensus is not to ever do History,
people should express on the sipping list that the requirements are bogus.

Cullen


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



From daemon@optimus.ietf.org  Fri May 24 04:46:00 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20474
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 04:46:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA26942
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 04:46:19 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25848;
	Fri, 24 May 2002 04:23:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA25820
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 04:23:11 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20100
	for <sip@ietf.org>; Fri, 24 May 2002 04:22:51 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4O8NAmG018028;
	Fri, 24 May 2002 10:23:10 +0200 (MEST)
Received: from ericsson.com (ppp10.lmf.ericsson.se [131.160.102.10])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4O8N89q011409;
	Fri, 24 May 2002 11:23:08 +0300 (EET DST)
Message-ID: <3CEDF86D.E97B2C7D@ericsson.com>
Date: Fri, 24 May 2002 11:23:09 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: sip@ietf.org
References: <DLEHICEBMNEIPCACNLPCEEELCDAA.fluffy@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: draft-garcia-sip-called-party-id and history
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Cullen:

We are moving into dangerous grounds, because you want to solve the
history issue. The aim of this header is much more narrower in scope.
We don't want to solve the history problem. We just want to send an
indication to the UAS with one out of many identities that the INVITE
was sent.

You claim that a non compatible Called-Party will complicate getting 
history done, and I disagree with this point.

In the first proposal you make, the P-History would look like:

P-History: sip:user1-business@example.com

which is exactly the same as:

P-Called-Party-ID: sip:user1-business@example.com

with the exception that the P-Called-Party-ID contains the semantics
of the header, why P-History is broader and we need to include something
else to give a hint to the UAS.

I suspect that is the reason why you have your second proposal, which is:

P-History:
sip:user1-business@example.com;reason=SIP;cause=302;text="registrar
retargeted"

And this is the problem to me. We would need to define the reason, 
cause, text, etc, for all the situations where a proxy retargets a
URI. Isn't this the whole History header that still is requirements
phase?

I don't see any incompatibility problem if we have a P-Called-Party-ID
with a clear and simple semantics, at the same time that we work 
towards a broad History, that has to include the requirements of a
P-Called-Party-ID, and will eventually take over the P-Called-Party-ID.

/Miguel

>
Cullen Jennings wrote:
> 
> I see this draft as dealing with the issue of a proxy retargeting
> sip:user1-business@example.com to sip:user1@192.0.2.4
> 
> As a proposed change, how would you feel about changing the syntax from
> P-Called-Party-ID to something like
> 
> P-History: sip:user1-business@example.com
> or
> P-History:
> sip:user1-business@example.com;reason=SIP;cause=302;text="registrar
> retargeted"
> 
> I understand that 3G wishes to resolve this by June, however, I think that
> if we wanted to, we could do a P-History just as fast as a
> P-Called-Party-ID. The existence of a non compatible Called-Party will
> complicate getting History done. If the consensus is not to ever do History,
> people should express on the sipping list that the requirements are bogus.
> 
> Cullen

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Fri May 24 07:20:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23257
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 07:20:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA03278
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:20:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01998;
	Fri, 24 May 2002 06:49:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01969
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 06:49:38 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22672
	for <sip@ietf.org>; Fri, 24 May 2002 06:49:17 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4OAnaH25885
	for <sip@ietf.org>; Fri, 24 May 2002 06:49:36 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <KTF9XBGX>; Fri, 24 May 2002 11:49:35 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB0051B49D2@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Mark Watson <mwatson@nortelnetworks.com>,
        "'Peterson, Jon'"
	 <jon.peterson@neustar.biz>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Fri, 24 May 2002 11:49:34 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

With a 3GPP hat on, just to confirm that the "hint" is as much part of the 3GPP requirements as is the Asserted-Identity, and both are absolutely essential to the release we are trying to freeze now.

Moreover, things are now running pretty close to the wire in terms of getting this in. Can we have a decision on this as soon as possible, and then get the revised drafts out for discussion on the SIP list, so we can get a clear idea of what the SIP working group view is. I do not think we really mind what the decision is; is there an IETF equivalent of tossing a coin? Within 3GPP we have got about as far as we get on this issue without going away and making it up for ourselves.

And before anybody says yet again that this is a 3GPP only solution, I would point out that at both the SIP/SIPPING ad-hoc and in Las Vegas and on this list, the wireline operator's have been shouting for it just as much.

Keith

> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> Sent: 22 May 2002 14:59
> To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> Importance: High
> 
> 
> All,
> 
> Can we have a *decision* asap as to whether the 'hint' uses
> Asserted-Identity, or another header in another draft.
> 
> I do not mind which. If the latter I will publish an I-D 
> describing it as
> soon as we have a decision, assuming it is this week, since 
> I'm away next
> week.
> 
> If we do nothing, then I guess 3GPP will make up its own mind 
> how to do
> this, without supervision or advice from IETF, which I think 
> would  be a bad
> thing.
> 
> Regards...Mark
> 
> 
> -----Original Message-----
> From: Watson, Mark [MDN05:EP10:EXCH] 
> Sent: 20 May 2002 12:08
> To: 'Peterson, Jon'; 'Rohan Mahy'
> Cc: sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> 
> The 'hint' was one of the three requirements that 3GPP 
> communicated to us in
> April. 
> It is a separate requirement from the Network Asserted 
> Identity itself, and
> so is not addressed in the requirements draft, although I 
> have been careful
> to point this out, and to point out that it is a requirement 
> nontheless, on
> several occasions.
> I believe we need the 'hint' in the same timeframe as the 
> rest of the short
> term work. 
> Whether it is the same header/draft or a different 
> header/draft is another
> question on which I will only say that we'd better make up 
> our minds pretty
> quick.
> ...Mark 
> 
> 
> > -----Original Message----- 
> > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
> > Sent: 19 May 2002 18:11 
> > To: 'Rohan Mahy' 
> > Cc: sip@ietf.org 
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > 
> > 
> > 
> > My argument was not that the proposed hint won't work - just 
> > that it isn't 
> > necessary to solve the problem at hand. It might not be the 
> > case that the 
> > problems with the hint stop at the philosophical point you 
> > mention below. 
> > What I asked in my last mail was not whether or not we needed 
> > a hint, but 
> > rather whether or not we should table that question until we 
> > resolve the 
> > other questions at hand. I just don't want to spend the 
> > cycles arguing about 
> > the hint given our very aggressive timetable - frankly, I 
> think that 
> > reaching consensus on this hint matter might push back our 
> > dates a bit. 
> > Let's investigate this hint stuff in June, but for now just 
> > figure out how a 
> > Trust Domain can manage an asserted identity in a message. 
> > 
> > Jon Peterson 
> > NeuStar, Inc. 
> > 
> > > -----Original Message----- 
> > > From: Rohan Mahy [mailto:rohan@cisco.com] 
> > > Sent: Sunday, May 19, 2002 8:29 AM 
> > > To: Peterson, Jon 
> > > Cc: sip@ietf.org 
> > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? 
> > > 
> > > 
> > > Hi, 
> > > 
> > > The requirement for a hint is well understood, limited in 
> > > scope, and well motivated in the draft.  Nobody has identified 
> > > any technical reason why the hint won't work.   Your argument 
> > > that allowing a hint weakens the strength of the language on 
> > > ignoring Asserted-Identity from untrusted parties is purely 
> > > philosophical in nature.  I don't buy your argument. 
> > > 
> > > thanks, 
> > > -rohan 
> > > 
> > > 
> > > ---- Original message ---- 
> > > >Date: Fri, 17 May 2002 16:02:11 -0500 
> > > >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> > > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > > >To: "'sip@ietf.org'" <sip@ietf.org> 
> > > > 
> > > > 
> > > >In the course of the discussion between Mark Watson, Cullen 
> > > Jennings and 
> > > >myself about the short-term identity work, we have returned a 
> > > few times to 
> > > >the question of the infamous hint. This hint is, of course, a 
> > > way that a 
> > > >user agent (one that is not a member of the Trust Domain in 
> > > the short-term 
> > > >network asserted identity space) can provide a 'hint' to the 
> > > intermediary 
> > > >that will generate an Asserted-Identity indicating which 
> > > identity among 
> > > >several possibilities should be asserted. 
> > > > 
> > > >The need for this arises particularly from the 3G space, in 
> > > which the 
> > > >authentication process takes place independently of SIP and 
> > > does not carry 
> > > >this sort of personal identity information. It also assumes 
> > > that the 
> > > >operators of the intermediary in question are aware of 
> > > several legitimate 
> > > >identities which the user can elect to assert. 
> > > > 
> > > >It has been proposed on the mailing list and elsewhere that the 
> > > >Asserted-Identity header should be re-used by user agents 
> > > outside the Trust 
> > > >Domain to provide such a hint. I see a number of reasons for 
> > > and against 
> > > >using the Asserted-Identity for this purpose. For example, 
> > > today, there is a 
> > > >requirement that asserted-identities which are transmitted 
> > > from untrusted 
> > > >sources should not be used in any way - this would seem to 
> > > weaken that 
> > > >requirement. There is also possibly some behavior that still 
> > > needs to be 
> > > >specified (like how an intermediary would reject or otherwise 
> > > handle a 
> > > >request with an inappropriate hint) that might be impactful 
> > > to our choice. 
> > > > 
> > > >For the time being, however, I would like to suggest that 
> > > providing the hint 
> > > >is outside the scope of the current deliverables (the 
> > > asserted-identity 
> > > >requirements and mechanism drafts), which need to be 
> > > complete, as we 
> > > >discussed in the interim meeting, by the end of this month. I 
> > > believe that a 
> > > >separate draft should propose the use of Asserted-Identity or 
> > > any other 
> > > >header for this hint (in whatever timeframe is appropriate 
> > > for 3G's 
> > > >requirements), but that we should not speak to this matter in 
> > > the current 
> > > >asserted-identity deliverables. There is, as I see it, no 
> > > dependency on 
> > > >defining this hint before we dictate how intermediaries will 
> > > assert 
> > > >identities. 
> > > > 
> > > >Any comments on this plan? 
> > > > 
> > > >Jon Peterson 
> > > >NeuStar, Inc. 
> > > > 
> > > >_______________________________________________ 
> > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip 
> > > >This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Fri May 24 07:41:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24017
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 07:41:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA04632
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:41:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03488;
	Fri, 24 May 2002 07:22:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03401
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 07:22:21 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23484;
	Fri, 24 May 2002 07:21:57 -0400 (EDT)
Message-Id: <200205241121.HAA23484@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 24 May 2002 07:21:57 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-referredby-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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 Referred-By Mechanism
	Author(s)	: R. Sparks
	Filename	: draft-ietf-sip-referredby-00.txt
	Pages		: 23
	Date		: 23-May-02
	
The SIP REFER method [2] provides a mechanism where one party (the
referror) provides a second party (the referree) with an arbitrary
URI to reference.  If that URI is a SIP URI, the referree will send a
SIP request, often an INVITE, to that URI (the refer target).  This
document extends the REFER method allowing the referror to provide
information about the reference to the refer target using the
referree as an intermediary.  This information includes the identity
of the referror and the URI to which the referror referred.  The
mechanism utilizes S/MIME to help protect this information from a
malicious intermediary.  This protection is optional, but a recipient
may refuse to accept a request unless it is present

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

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

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

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


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

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

--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:	<20020523132730.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-referredby-00.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 24 07:41:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24040
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 07:41:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA04654
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:41:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03460;
	Fri, 24 May 2002 07:22:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03348
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 07:22:18 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23467;
	Fri, 24 May 2002 07:21:52 -0400 (EDT)
Message-Id: <200205241121.HAA23467@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 24 May 2002 07:21:52 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-call-auth-06.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: SIP Extensions for Media Authorization
	Author(s)	: W. Marshall, F. Andreasen, D. Evans
	Filename	: draft-ietf-sip-call-auth-06.txt
	Pages		: 16
	Date		: 23-May-02
	
This document describes the need for QoS and media authorization and 
defines a SIP extension that can be used to integrate QoS admission 
control with call signaling and help guard against denial of service 
attacks. The use of this extension is only applicable in 
administrative domains, or among federations of administrative 
domains with previously agreed-upon policies, where both the SIP 
proxy authorizing the QoS, and the policy control of the underlying 
network providing the QoS belong to that administrative domain or 
federation of domains.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-call-auth-06.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 24 07:42:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24084
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 07:42:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA04695
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:42:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04285;
	Fri, 24 May 2002 07:32:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03541
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 07:24:22 -0400 (EDT)
Received: from mailhost.wellx.com (mailhost.wellx.com [62.161.157.1])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA23542
	for <sip@ietf.org>; Fri, 24 May 2002 07:24:01 -0400 (EDT)
Received: from mail.wellx.com by mailhost.wellx.com
          via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 24 May 2002 11:17:28 UT
Received: from wellx.com (SIP [192.168.1.114]) by srvwellx.wellx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id JR6DTHPD; Fri, 24 May 2002 13:18:18 +0200
Message-ID: <3CEE254A.FAB45662@wellx.com>
Date: Fri, 24 May 2002 13:34:34 +0200
From: Aymeric MOIZARD <aymeric.moizard@wellx.com>
Organization: WellX
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: sip@ietf.org
References: <475FF955A05DD411980D00508B6D5FB0051B49D2@en0033exch001u.uk.lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Matching request for server transaction
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Reading the 17.23 section about the rules used to
match a request, I found a possible issue.

The spec says: [we must check the via branch, via sent-by
parameter] "and in the case of a CANCEL
request, the method of the request that created
the transaction was also CANCEL.

In the case where a pending CANCEL is going on and
we are receiving an retransmission of INVITE. The
INVITE will contains the same via branch and sent-by
and is not a CANCEL, so it will match the CANCEL
transaction according the rules defined. (the test
expect us to test the method only for CANCEL request!)

I am true if I say that the cseq method must always
be compared and not only for CSeq?

Aymeric


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



From daemon@optimus.ietf.org  Fri May 24 07:42:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24104
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 07:42:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA04709
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 07:42:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03336;
	Fri, 24 May 2002 07:21:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03305
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 07:21:48 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23370;
	Fri, 24 May 2002 07:21:22 -0400 (EDT)
Message-Id: <200205241121.HAA23370@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 24 May 2002 07:21:22 -0400
Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-05.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: SIP Extension Header Field for Service Route Discovery
                          in Private Networks
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-scvrtdisco-05.txt
	Pages		: 15
	Date		: 23-May-02
	
This document proposes a private SIP extension header used in
conjunction with responses to REGISTER messages to provide a
mechanism by which a registrar may inform a registering UA of a
service route that the UA may use to request outbound services from
the registrar's domain.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-willis-sip-scvrtdisco-05.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 24 08:22:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25278
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 08:22:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA06409
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 08:22:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05957;
	Fri, 24 May 2002 08:03:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA05908
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 08:03:34 -0400 (EDT)
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24627
	for <sip@ietf.org>; Fri, 24 May 2002 08:03:13 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4OC2RI13787;
	Fri, 24 May 2002 07:02:27 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25Z4GMK>; Fri, 24 May 2002 07:02:22 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Andrew Allen'"
	 <AAllen@dynamicsoft.com>,
        "'David R. Oran'" <oran@cisco.com>, "'Rohan Mahy'" <rohan@cisco.com>,
        sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
Date: Fri, 24 May 2002 07:02:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2031A.DBB8F580"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

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

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

Since I've never been one to fly in the face of public opinion (cough), I'll
agree (at least in this case) that we should go with majority rule and use
the Asserted-Identity header for the 'hint'.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Mark Watson [mailto:mwatson@nortelnetworks.com]
Sent: Thursday, May 23, 2002 9:18 AM
To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy';
sip@ietf.org
Subject: RE: [Sip] Asserted-Identity: How to 'hint'?



In the absence of further comment, can I make a *proposal* that we stick
with Asserted-Identity for the hint and for the NAI itself, and that both
are described in Cullen's draft ?

Can we take this as AGREED if there are no comments by cob tomorrow ?
(Guidance sought from chairs on this second question).

Updated requirements draft to be submitted first thing tomorrow. 

Regards...Mark 

> -----Original Message----- 
> From: Andrew Allen [ mailto:AAllen@dynamicsoft.com
<mailto:AAllen@dynamicsoft.com> ] 
> Sent: 22 May 2002 15:51 
> To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon'; 
> 'Rohan Mahy'; sip@ietf.org 
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> 
> 
> 
> I agree with Dave. Lets put the hint in the 
> asserted-identity. Lets not have 
> two redundant headers that need to be transferred over the 
> Radio interface 
> unnecessarily. 
> 
> Andrew 
> 
> > -----Original Message----- 
> > From: David R. Oran [ mailto:oran@cisco.com <mailto:oran@cisco.com> ] 
> > Sent: Wednesday, May 22, 2002 9:45 AM 
> > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org 
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > 
> > 
> > I suggest we allow the hint to be placed in the 
> > asserted-identity rather 
> > than in another header. A boundary proxy has to deal with a 
> UA putting 
> > in the header no matter what, if only to reject the request with an 
> > error. 
> > 
> > Once we have a full solution the issue of hints should go 
> > away as a side 
> > effect of having the "authorization server" functionality that Jon 
> > proposes. Better IMHO to have one obsolescent header to deal 
> > with rather 
> > than two, as well as avoiding the concomitant verbiage 
> describing the 
> > combinatoric cases involving two headers. 
> > 
> > Dave. 
> > 
> > > -----Original Message----- 
> > > From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org
<mailto:sip-admin@ietf.org> ] On 
> > > Behalf Of Mark Watson 
> > > Sent: Wednesday, May 22, 2002 9:59 AM 
> > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org 
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > > Importance: High 
> > > 
> > > 
> > > All, 
> > > 
> > > Can we have a *decision* asap as to whether the 'hint' uses 
> > > Asserted-Identity, or another header in another draft. 
> > > 
> > > I do not mind which. If the latter I will publish an I-D 
> > > describing it as soon as we have a decision, assuming it is 
> > > this week, since I'm away next week. 
> > > 
> > > If we do nothing, then I guess 3GPP will make up its own mind 
> > > how to do this, without supervision or advice from IETF, 
> > > which I think would  be a bad thing. 
> > > 
> > > Regards...Mark 
> > > 
> > > 
> > > -----Original Message----- 
> > > From: Watson, Mark [MDN05:EP10:EXCH] 
> > > Sent: 20 May 2002 12:08 
> > > To: 'Peterson, Jon'; 'Rohan Mahy' 
> > > Cc: sip@ietf.org 
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > > 
> > > 
> > > The 'hint' was one of the three requirements that 3GPP 
> > > communicated to us in April. 
> > > It is a separate requirement from the Network Asserted 
> > > Identity itself, and so is not addressed in the requirements 
> > > draft, although I have been careful to point this out, and to 
> > > point out that it is a requirement nontheless, on several 
> > > occasions. I believe we need the 'hint' in the same timeframe 
> > > as the rest of the short term work. 
> > > Whether it is the same header/draft or a different 
> > > header/draft is another question on which I will only say 
> > > that we'd better make up our minds pretty quick. ...Mark 
> > > 
> > > 
> > > > -----Original Message----- 
> > > > From: Peterson, Jon [ mailto:jon.peterson@neustar.biz
<mailto:jon.peterson@neustar.biz> ] 
> > > > Sent: 19 May 2002 18:11 
> > > > To: 'Rohan Mahy' 
> > > > Cc: sip@ietf.org 
> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
> > > > 
> > > > 
> > > > 
> > > > My argument was not that the proposed hint won't work - just 
> > > > that it isn't 
> > > > necessary to solve the problem at hand. It might not be the 
> > > > case that the 
> > > > problems with the hint stop at the philosophical point you 
> > > > mention below. 
> > > > What I asked in my last mail was not whether or not we needed 
> > > > a hint, but 
> > > > rather whether or not we should table that question until we 
> > > > resolve the 
> > > > other questions at hand. I just don't want to spend the 
> > > > cycles arguing about 
> > > > the hint given our very aggressive timetable - frankly, I 
> > > think that 
> > > > reaching consensus on this hint matter might push back our 
> > > > dates a bit. 
> > > > Let's investigate this hint stuff in June, but for now just 
> > > > figure out how a 
> > > > Trust Domain can manage an asserted identity in a message. 
> > > > 
> > > > Jon Peterson 
> > > > NeuStar, Inc. 
> > > > 
> > > > > -----Original Message----- 
> > > > > From: Rohan Mahy [ mailto:rohan@cisco.com <mailto:rohan@cisco.com>
] 
> > > > > Sent: Sunday, May 19, 2002 8:29 AM 
> > > > > To: Peterson, Jon 
> > > > > Cc: sip@ietf.org 
> > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'? 
> > > > > 
> > > > > 
> > > > > Hi, 
> > > > > 
> > > > > The requirement for a hint is well understood, limited in 
> > > > > scope, and well motivated in the draft.  Nobody has 
> identified 
> > > > > any technical reason why the hint won't work.   Your argument 
> > > > > that allowing a hint weakens the strength of the language on 
> > > > > ignoring Asserted-Identity from untrusted parties is purely 
> > > > > philosophical in nature.  I don't buy your argument. 
> > > > > 
> > > > > thanks, 
> > > > > -rohan 
> > > > > 
> > > > > 
> > > > > ---- Original message ---- 
> > > > > >Date: Fri, 17 May 2002 16:02:11 -0500 
> > > > > >From: "Peterson, Jon" <jon.peterson@neustar.biz>  
> > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'?  
> > > > > >To: "'sip@ietf.org'" <sip@ietf.org> 
> > > > > > 
> > > > > > 
> > > > > >In the course of the discussion between Mark Watson, Cullen 
> > > > > Jennings and 
> > > > > >myself about the short-term identity work, we have returned a 
> > > > > few times to 
> > > > > >the question of the infamous hint. This hint is, of course, a 
> > > > > way that a 
> > > > > >user agent (one that is not a member of the Trust Domain in 
> > > > > the short-term 
> > > > > >network asserted identity space) can provide a 'hint' to the 
> > > > > intermediary 
> > > > > >that will generate an Asserted-Identity indicating which 
> > > > > identity among 
> > > > > >several possibilities should be asserted. 
> > > > > > 
> > > > > >The need for this arises particularly from the 3G space, in 
> > > > > which the 
> > > > > >authentication process takes place independently of SIP and 
> > > > > does not carry 
> > > > > >this sort of personal identity information. It also assumes 
> > > > > that the 
> > > > > >operators of the intermediary in question are aware of 
> > > > > several legitimate 
> > > > > >identities which the user can elect to assert. 
> > > > > > 
> > > > > >It has been proposed on the mailing list and 
> elsewhere that the 
> > > > > >Asserted-Identity header should be re-used by user agents 
> > > > > outside the Trust 
> > > > > >Domain to provide such a hint. I see a number of reasons for 
> > > > > and against 
> > > > > >using the Asserted-Identity for this purpose. For example, 
> > > > > today, there is a 
> > > > > >requirement that asserted-identities which are transmitted 
> > > > > from untrusted 
> > > > > >sources should not be used in any way - this would seem to 
> > > > > weaken that 
> > > > > >requirement. There is also possibly some behavior that still 
> > > > > needs to be 
> > > > > >specified (like how an intermediary would reject or otherwise 
> > > > > handle a 
> > > > > >request with an inappropriate hint) that might be impactful 
> > > > > to our choice. 
> > > > > > 
> > > > > >For the time being, however, I would like to suggest that 
> > > > > providing the hint 
> > > > > >is outside the scope of the current deliverables (the 
> > > > > asserted-identity 
> > > > > >requirements and mechanism drafts), which need to be 
> > > > > complete, as we 
> > > > > >discussed in the interim meeting, by the end of this month. I 
> > > > > believe that a 
> > > > > >separate draft should propose the use of Asserted-Identity or 
> > > > > any other 
> > > > > >header for this hint (in whatever timeframe is appropriate 
> > > > > for 3G's 
> > > > > >requirements), but that we should not speak to this matter in 
> > > > > the current 
> > > > > >asserted-identity deliverables. There is, as I see it, no 
> > > > > dependency on 
> > > > > >defining this hint before we dictate how intermediaries will 
> > > > > assert 
> > > > > >identities. 
> > > > > > 
> > > > > >Any comments on this plan? 
> > > > > > 
> > > > > >Jon Peterson 
> > > > > >NeuStar, Inc. 
> > > > > > 
> > > > > >_______________________________________________ 
> > > > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
<https://www1.ietf.org/mailman/listinfo/sip>  
> > > > > >This list is for NEW development of the core SIP 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
<https://www1.ietf.org/mailman/listinfo/sip>  
> > > > This list is for NEW development of the core SIP 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
<https://www1.ietf.org/mailman/listinfo/sip>  
> > > This list is for NEW development of the core SIP 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
<https://www1.ietf.org/mailman/listinfo/sip>  
> > This list is for NEW development of the core SIP 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_01C2031A.DBB8F580
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [Sip] Asserted-Identity: How to 'hint'?</TITLE>

<META content="MSHTML 5.00.3315.2870" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=275475911-24052002>Since 
I've never been one to fly in the face of public opinion (cough), I'll 
agree&nbsp;(at least in this case) that we should go with majority rule and use 
the Asserted-Identity header for the 'hint'.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=275475911-24052002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=275475911-24052002>Jon 
Peterson</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=275475911-24052002>NeuStar, Inc.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Mark Watson 
  [mailto:mwatson@nortelnetworks.com]<BR><B>Sent:</B> Thursday, May 23, 2002 
  9:18 AM<BR><B>To:</B> 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan 
  Mahy'; sip@ietf.org<BR><B>Subject:</B> RE: [Sip] Asserted-Identity: How to 
  'hint'?<BR><BR></DIV></FONT>
  <P><FONT size=2>In the absence of further comment, can I make a *proposal* 
  that we stick with Asserted-Identity for the hint and for the NAI itself, and 
  that both are described in Cullen's draft ?</FONT></P>
  <P><FONT size=2>Can we take this as AGREED if there are no comments by cob 
  tomorrow ? (Guidance sought from chairs on this second question).</FONT></P>
  <P><FONT size=2>Updated requirements draft to be submitted first thing 
  tomorrow.</FONT> </P>
  <P><FONT size=2>Regards...Mark</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Andrew Allen [<A 
  href="mailto:AAllen@dynamicsoft.com">mailto:AAllen@dynamicsoft.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: 22 May 2002 15:51</FONT> <BR><FONT size=2>&gt; To: 
  'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon';</FONT> 
  <BR><FONT size=2>&gt; 'Rohan Mahy'; sip@ietf.org</FONT> <BR><FONT size=2>&gt; 
  Subject: RE: [Sip] Asserted-Identity: How to 'hint'?</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; I agree with Dave. Lets put the hint in the 
  </FONT><BR><FONT size=2>&gt; asserted-identity. Lets not have</FONT> <BR><FONT 
  size=2>&gt; two redundant headers that need to be transferred over the 
  </FONT><BR><FONT size=2>&gt; Radio interface</FONT> <BR><FONT size=2>&gt; 
  unnecessarily.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  Andrew</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; 
  -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; From: David R. 
  Oran [<A href="mailto:oran@cisco.com">mailto:oran@cisco.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; Sent: Wednesday, May 22, 2002 9:45 AM</FONT> 
  <BR><FONT size=2>&gt; &gt; To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; 
  sip@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; Subject: RE: [Sip] 
  Asserted-Identity: How to 'hint'?</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I suggest 
  we allow the hint to be placed in the </FONT><BR><FONT size=2>&gt; &gt; 
  asserted-identity rather</FONT> <BR><FONT size=2>&gt; &gt; than in another 
  header. A boundary proxy has to deal with a </FONT><BR><FONT size=2>&gt; UA 
  putting</FONT> <BR><FONT size=2>&gt; &gt; in the header no matter what, if 
  only to reject the request with an</FONT> <BR><FONT size=2>&gt; &gt; 
  error.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  Once we have a full solution the issue of hints should go </FONT><BR><FONT 
  size=2>&gt; &gt; away as a side</FONT> <BR><FONT size=2>&gt; &gt; effect of 
  having the "authorization server" functionality that Jon</FONT> <BR><FONT 
  size=2>&gt; &gt; proposes. Better IMHO to have one obsolescent header to deal 
  </FONT><BR><FONT size=2>&gt; &gt; with rather</FONT> <BR><FONT size=2>&gt; 
  &gt; than two, as well as avoiding the concomitant verbiage </FONT><BR><FONT 
  size=2>&gt; describing the</FONT> <BR><FONT size=2>&gt; &gt; combinatoric 
  cases involving two headers.</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; Dave.</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; -----Original Message-----</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; From: sip-admin@ietf.org [<A 
  href="mailto:sip-admin@ietf.org">mailto:sip-admin@ietf.org</A>] On 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; Behalf Of Mark Watson</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; Sent: Wednesday, May 22, 2002 9:59 AM</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Subject: RE: [Sip] Asserted-Identity: How to 
  'hint'?</FONT> <BR><FONT size=2>&gt; &gt; &gt; Importance: High</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; All,</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Can we have a *decision* asap as 
  to whether the 'hint' uses </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  Asserted-Identity, or another header in another draft.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; I do not mind 
  which. If the latter I will publish an I-D </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; describing it as soon as we have a decision, assuming it is 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; this week, since I'm away next 
  week.</FONT> <BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; If we do nothing, then I guess 3GPP will make up its own mind 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; how to do this, without supervision or 
  advice from IETF, </FONT><BR><FONT size=2>&gt; &gt; &gt; which I think 
  would&nbsp; be a bad thing.</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; Regards...Mark</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; From: Watson, Mark [MDN05:EP10:EXCH] </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; Sent: 20 May 2002 12:08</FONT> <BR><FONT size=2>&gt; &gt; &gt; To: 
  'Peterson, Jon'; 'Rohan Mahy'</FONT> <BR><FONT size=2>&gt; &gt; &gt; Cc: 
  sip@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; &gt; Subject: RE: [Sip] 
  Asserted-Identity: How to 'hint'?</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  The 'hint' was one of the three requirements that 3GPP </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; communicated to us in April. </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; It is a separate requirement from the Network Asserted 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; Identity itself, and so is not 
  addressed in the requirements </FONT><BR><FONT size=2>&gt; &gt; &gt; draft, 
  although I have been careful to point this out, and to </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; point out that it is a requirement nontheless, on 
  several </FONT><BR><FONT size=2>&gt; &gt; &gt; occasions. I believe we need 
  the 'hint' in the same timeframe </FONT><BR><FONT size=2>&gt; &gt; &gt; as the 
  rest of the short term work. </FONT><BR><FONT size=2>&gt; &gt; &gt; Whether it 
  is the same header/draft or a different </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  header/draft is another question on which I will only say </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; that we'd better make up our minds pretty quick. ...Mark 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; -----Original Message-----</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; From: Peterson, Jon [<A 
  href="mailto:jon.peterson@neustar.biz">mailto:jon.peterson@neustar.biz</A>] 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; Sent: 19 May 2002 18:11 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; To: 'Rohan Mahy' </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; Cc: sip@ietf.org </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; &gt; Subject: RE: [Sip] Asserted-Identity: How to 'hint'? 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; My argument was not that the proposed hint won't 
  work - just</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; that it isn't 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; necessary to solve the problem at 
  hand. It might not be the </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; case 
  that the </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; problems with the hint 
  stop at the philosophical point you </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  &gt; mention below. </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; What I asked 
  in my last mail was not whether or not we needed </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; &gt; a hint, but </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; rather 
  whether or not we should table that question until we </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; resolve the </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  &gt; other questions at hand. I just don't want to spend the </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; cycles arguing about </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; &gt; the hint given our very aggressive timetable - frankly, I 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; think that </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; &gt; reaching consensus on this hint matter might push back our 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; dates a bit. </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; Let's investigate this hint stuff in June, but for 
  now just </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; figure out how a 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; Trust Domain can manage an 
  asserted identity in a message. </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; Jon Peterson</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; NeuStar, Inc. </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; -----Original 
  Message-----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; From: Rohan Mahy 
  [<A href="mailto:rohan@cisco.com">mailto:rohan@cisco.com</A>] </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; Sent: Sunday, May 19, 2002 8:29 AM 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; To: Peterson, Jon 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Cc: sip@ietf.org 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; Subject: Re: [Sip] 
  Asserted-Identity: How to 'hint'? </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; Hi,</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; The requirement for 
  a hint is well understood, limited in</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; scope, and well motivated in the draft.&nbsp; Nobody has 
  </FONT><BR><FONT size=2>&gt; identified </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; any technical reason why the hint won't work.&nbsp;&nbsp; Your 
  argument </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; that allowing a hint 
  weakens the strength of the language on </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; ignoring Asserted-Identity from untrusted parties is purely 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; philosophical in 
  nature.&nbsp; I don't buy your argument. </FONT><BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; thanks,</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; -rohan </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; ---- Original message 
  ----</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;Date: Fri, 17 May 
  2002 16:02:11 -0500</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;From: 
  "Peterson, Jon" &lt;jon.peterson@neustar.biz&gt;&nbsp; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;Subject: [Sip] Asserted-Identity: How to 
  'hint'?&nbsp; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;To: 
  "'sip@ietf.org'" &lt;sip@ietf.org&gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;In the course of the 
  discussion between Mark Watson, Cullen</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; Jennings and</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;myself about the short-term identity work, we have returned a</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; few times to</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;the question of the infamous hint. This 
  hint is, of course, a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; way 
  that a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;user agent (one 
  that is not a member of the Trust Domain in</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt; the short-term</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;network asserted identity space) can provide a 'hint' to the</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; intermediary</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;that will generate an Asserted-Identity 
  indicating which</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; identity 
  among</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;several 
  possibilities should be asserted.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;The need for 
  this arises particularly from the 3G space, in</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt; which the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;authentication process takes place independently of SIP and</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; does not carry</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;this sort of personal identity 
  information. It also assumes</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  that the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;operators of the 
  intermediary in question are aware of</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; several legitimate</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;identities which the user can elect to assert.</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; &gt;It has been proposed on the mailing list and </FONT><BR><FONT 
  size=2>&gt; elsewhere that the</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; 
  &gt; &gt;Asserted-Identity header should be re-used by user agents 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; outside the Trust</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;Domain to provide such a hint. I 
  see a number of reasons for</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  and against</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;using the 
  Asserted-Identity for this purpose. For example,</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt; today, there is a</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; &gt;requirement that asserted-identities which are 
  transmitted</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; from 
  untrusted</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;sources should 
  not be used in any way - this would seem to</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt; weaken that</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;requirement. There is also possibly some behavior that still</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; needs to be</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;specified (like how an intermediary would 
  reject or otherwise</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; handle 
  a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;request with an 
  inappropriate hint) that might be impactful</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt; to our choice.</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;For the time being, 
  however, I would like to suggest that</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; providing the hint</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;is outside the scope of the current deliverables (the</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; asserted-identity</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt; &gt;requirements and mechanism drafts), which need to 
  be</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; complete, as we</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;discussed in the interim 
  meeting, by the end of this month. I</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; believe that a</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;separate draft should propose the use of Asserted-Identity or</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; any other</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;header for this hint (in whatever 
  timeframe is appropriate</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; for 
  3G's</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;requirements), but 
  that we should not speak to this matter in</FONT> <BR><FONT size=2>&gt; &gt; 
  &gt; &gt; &gt; the current</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;asserted-identity deliverables. There is, as I see it, no</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; dependency on</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt; &gt;defining this hint before we dictate how 
  intermediaries will</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  assert</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;identities.</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; &gt; &gt; &gt;Any comments on this plan?</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; &gt;Jon Peterson</FONT> <BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;NeuStar, Inc. </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; 
  &gt;_______________________________________________</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;Sip mailing list&nbsp; <A 
  href="https://www1.ietf.org/mailman/listinfo/sip" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/sip</A> </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; &gt;This list is for NEW development of the 
  core SIP Protocol </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;Use 
  sip-implementors@cs.columbia.edu for questions on </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; current sip </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; &gt; &gt;Use 
  sipping@ietf.org for new developments on the application </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; &gt; of sip</FONT> <BR><FONT size=2>&gt; &gt; &gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; &gt; Sip mailing list&nbsp; <A 
  href="https://www1.ietf.org/mailman/listinfo/sip" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/sip</A> </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; &gt; This list is for NEW development of the core SIP 
  Protocol </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; Use 
  sip-implementors@cs.columbia.edu for questions on </FONT><BR><FONT size=2>&gt; 
  current sip </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; Use sipping@ietf.org 
  for new developments on the </FONT><BR><FONT size=2>&gt; &gt; application of 
  sip </FONT><BR><FONT size=2>&gt; &gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; Sip mailing list&nbsp; <A 
  href="https://www1.ietf.org/mailman/listinfo/sip" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/sip</A></FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; This list is for NEW development of the core SIP 
  Protocol</FONT> <BR><FONT size=2>&gt; &gt; &gt; Use 
  sip-implementors@cs.columbia.edu for questions on current sip</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; Use sipping@ietf.org for new developments on the 
  </FONT><BR><FONT size=2>&gt; application of sip</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  &gt; Sip mailing list&nbsp; <A 
  href="https://www1.ietf.org/mailman/listinfo/sip" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/sip</A></FONT> <BR><FONT 
  size=2>&gt; &gt; This list is for NEW development of the core SIP 
  Protocol</FONT> <BR><FONT size=2>&gt; &gt; Use 
  sip-implementors@cs.columbia.edu for questions on current sip</FONT> <BR><FONT 
  size=2>&gt; &gt; Use sipping@ietf.org for new developments on the application 
  of sip</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
  </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2031A.DBB8F580--

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



From daemon@optimus.ietf.org  Fri May 24 10:21:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29812
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 10:21:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA12962
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 10:22:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12476;
	Fri, 24 May 2002 10:09:40 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA12431
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 10:09:37 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29451
	for <sip@ietf.org>; Fri, 24 May 2002 10:09:14 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA02528;
	Fri, 24 May 2002 16:09:20 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA19941;
	Fri, 24 May 2002 16:09:33 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LL4YTTVA>; Fri, 24 May 2002 16:09:39 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DD9@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: sip@ietf.org
Subject: [Sip] Comments on draft-garcia-sip-called-party-id-01
Date: Fri, 24 May 2002 16:09:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

- Reading the draft for the first time, I must say that I was confused by
the 4th 
  paragraph of the Section 2 which starts with "Another possible solution to
the 
  problem is...". Up to this point the draft talks about the problem, with
no
  solution mentioned yet. With the "Another possible solution", I thought I
had
  a corrupted version of the draft with some paragraphs missing.

- The next paragraph which starts with "The solution described above...",
the
  sentence "that some URIs may be automatically registered when the UA
  registers some of its URIs" confused me further.

- Is the term "terminating ID" (of the current INVITE) defined somewhere ? I
think
  you mean "the destination (request-URI) of the request before it was
replaced
  by the contact address".

- In the example, the sentence above the mesage F2 starts with
  "A user also...", do you actually mean "The user also..." ?

- The last paragraph of Section 2 :
  "... the proxy that is serving the user..." should be made clearer,
perhaps with
  "the proxy that is responsible for the home domain (as defined in RFC
3261) of
  the user" ? Also, please add a "header" after the P-Called-Party-ID in the
same
  sentence.

- Section 3
  "1. The UA registers to his proxy with one or more SIP URIs". Does it have
to be
   SIP URIs or can it be "SIP or SIPS URIs" ? I assume you mean here that
the
   UA registers one or more address-of-record.
  "2. The proxy receives an INVITE destined to a user's ID" means :
  "2. An INVITE arrives at a proxy which is responsible for the domain of
the
       Request-URI".
  
  Come to think of it, these applicability statements apply to all SIP
requests in
  general. It is normal for a UA to register to his proxy with at least one
address-
  of-record, and some proxy always receives an INVITE destined to a user'
ID.
  I do not see how these statements meet the requirement of [3], which
states :

  "An applicability statement in the Informational RFC MUST
   clearly document the useful scope of the proposal, and explain
   its limitations and why it is not suitable for the general use
   of SIP in the Internet."

- Section 4 2nd paragraph
  o This paragraph seems to imply that any SIP proxy can insert the
     P-Call-Party-ID header field.
  o The term "standalone method" is not defined in SIP RFC.
  o INVITE is a method that initiates a dialog so it cannot be "INVITE or
    method that intiates a dialog".

- Section 5
  The sentence "The allowable usage of headers..." is repeated. The 3rd
  paragraph should be completely deleted.

- Section 6.2
  First paragraph
  o The term "standalone method" is not defined in SIP RFC.
  o INVITE is a method that initiates a dialog so it cannot be "INVITE or
    method that intiates a dialog".
  o "...contents Request-URI" => "...contents of the Request-URI..."

  Second paragraph
  o "...the proxy who..." => "...the proxy which..."


- Ya-Ching Tan



  











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



From daemon@optimus.ietf.org  Fri May 24 14:48:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10224
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 14:48:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA13547
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 14:48:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11103;
	Fri, 24 May 2002 14:29:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10876
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 14:29:08 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03467
	for <sip@ietf.org>; Fri, 24 May 2002 11:55:24 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA07613;
	Fri, 24 May 2002 17:55:30 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA09366;
	Fri, 24 May 2002 17:55:43 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LL4YT4FY>; Fri, 24 May 2002 17:55:49 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDA@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Comments on draft-garcia-sip-visited-network-id-01
Date: Fri, 24 May 2002 17:55:40 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

 - General
   The term 'standalone request'  or 'standalone transaction
   request' is used throughout the document. Please define
   what it means.

 - 3rd paragraph of Section 1
   "... it seems sensitive..." should be "... it seems sensible..."

 - Section 2, point 3 "There is not requirement that..." should
   be "There is no requirement that ...", and at the end of the
   sentence, "in this memo" should be "in this document".

- Section 4
  Please delete the 1st sentence "The P-Visited-Network-ID
  is an extension of a SIP header", or replace it with "This
  specification defines a new header field.

- 1st paragraph on page 4
  "..., a SIP node may insert a new P-Visited-Network-ID header,
  if there was already one present with different contents" is
  misleading. I think you meant :
  "..., a proxy MAY insert a new P-Visited-Network-ID header
  if the request does not contain any P-Visited-Network-ID header
  with the same network identifier as its own network identifier".

  Delete the "a vairous" in "...a various different administrative 
  domains"

- The addition to Table 2 in Section 4
  A "r" should be added to the "ad" under proxy. Proxies must
  be able to read this header.

- Section 5.1
  "The UA SHOULD NOT insert" should be "MUST NOT insert".
  I think the result can be disastrous if a UA inserts one.

- Section 5.2
  Replace "the contents of a provisioned string" with just "a text
  string" and delete the "at the user's home domain" at the end.
  Otherwise it reads like "identifies ...the proxy is operating
  at the user's home network", where it is not.

- 10.2
  draft-sipping-garcia-3gpp-req-03 should be
  draft-garcia-sipping-3gpp-req-03 instead. This same error
  is also in the called party id draft.


Regards,
Ya-Ching







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



From daemon@optimus.ietf.org  Fri May 24 14:55:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10473
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 14:55:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA13905
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 14:55:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12942;
	Fri, 24 May 2002 14:45:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA12752
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 14:45:16 -0400 (EDT)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05580
	for <sip@ietf.org>; Fri, 24 May 2002 13:00:42 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA28796;
	Fri, 24 May 2002 19:00:59 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA22591;
	Fri, 24 May 2002 19:01:01 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LL4YT4K8>; Fri, 24 May 2002 19:01:06 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDB@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'Miguel.A.Garcia@ericsson.com'" <Miguel.A.Garcia@ericsson.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: [Sip] Comments on draft-garcia-sip-visited-network-id-01
Date: Fri, 24 May 2002 19:00:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

 - General
   The term 'standalone request'  or 'standalone transaction
   request' is used throughout the document. Please define
   what it means.

 - 3rd paragraph of Section 1
   "... it seems sensitive..." should be "... it seems sensible..."

 - Section 2, point 3 "There is not requirement that..." should
   be "There is no requirement that ...", and at the end of the
   sentence, "in this memo" should be "in this document".

- Section 4
  Please delete the 1st sentence "The P-Visited-Network-ID
  is an extension of a SIP header", or replace it with "This
  specification defines a new header field.

- 1st paragraph on page 4
  "..., a SIP node may insert a new P-Visited-Network-ID header,
  if there was already one present with different contents" is
  misleading. I think you meant :
  "..., a proxy MAY insert a new P-Visited-Network-ID header
  if the request does not contain any P-Visited-Network-ID header
  with the same network identifier as its own network identifier".

  Delete the "a vairous" in "...a various different administrative 
  domains"

- The addition to Table 2 in Section 4
  A "r" should be added to the "ad" under proxy. Proxies must
  be able to read this header.

- Section 5.1
  "The UA SHOULD NOT insert" should be "MUST NOT insert".
  I think the result can be disastrous if a UA inserts one.

- Section 5.2
  Replace "the contents of a provisioned string" with just "a text
  string" and delete the "at the user's home domain" at the end.
  Otherwise it reads like "identifies ...the proxy is operating
  at the user's home network", where it is not.

- 10.2
  draft-sipping-garcia-3gpp-req-03 should be
  draft-garcia-sipping-3gpp-req-03 instead. This same error
  is also in the called party id draft.


Regards,
Ya-Ching




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



From daemon@optimus.ietf.org  Fri May 24 15:46:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12108
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 15:46:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA17060
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 15:46:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15577;
	Fri, 24 May 2002 15:29:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15509
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 15:28:55 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11412
	for <sip@ietf.org>; Fri, 24 May 2002 15:28:32 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4OJS6d08646;
	Fri, 24 May 2002 14:28:06 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <ehenrikson@lucent.com>, <rohan@cisco.com>, <jo@ipdialog.com>,
        <brian.rosen@marconi.com>
Date: Fri, 24 May 2002 14:27:32 -0500
Message-ID: <00b201c20359$0d927570$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Poll: Expert Review of draft-henrikson-sip-orig-dialog-id
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Yet another P-Header review. 

Please say anything you have to say about
draft-henrikson-sip-orig-dialog-id so we can decide whether to accept
it, reject it, or require further work.

Thanks,

--
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 daemon@optimus.ietf.org  Fri May 24 15:49:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12211
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 15:49:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA17210
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 15:49:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15553;
	Fri, 24 May 2002 15:28:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15502
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 15:28:54 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11411
	for <sip@ietf.org>; Fri, 24 May 2002 15:28:32 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4OJS6d08651;
	Fri, 24 May 2002 14:28:06 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        <ehenrikson@lucent.com>
Date: Fri, 24 May 2002 14:27:32 -0500
Message-ID: <00b301c20359$0e1bf0c0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Poll: expert review of draft-henrikson-sip-charging-information
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


You may recall that we're doing an Expert Review of
draft-henrikson-sip-charging-information.

If you have a strong opinion for, against, or supporting a need for
further work, or any further suggestions for enhancement, please post
them now.

--
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 daemon@optimus.ietf.org  Fri May 24 15:54:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12408
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 15:54:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA17395
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 15:54:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15626;
	Fri, 24 May 2002 15:29:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA15566
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 15:29:00 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11417
	for <sip@ietf.org>; Fri, 24 May 2002 15:28:37 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4OJS7d08654;
	Fri, 24 May 2002 14:28:07 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        "Miguel Garcia" <Miguel.A.Garcia@ericsson.com>
Date: Fri, 24 May 2002 14:27:32 -0500
Message-ID: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


I'd like to request feedback on the expert review of
draft-garcia-sip-associated URI:

Option:

   Yeah
   Nay
   Or Needs More Work

And of course, details on what and why . . .

Anybody out there have a Strong Opinion One Way or Another?

Thanks,

--
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 daemon@optimus.ietf.org  Fri May 24 17:57:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16613
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 17:57:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA24243
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 17:57:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23834;
	Fri, 24 May 2002 17:44:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23780
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 17:43:59 -0400 (EDT)
Received: from omta03.mta.everyone.net (sitemail3.everyone.net [216.200.145.37])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16139
	for <sip@ietf.org>; Fri, 24 May 2002 17:43:38 -0400 (EDT)
Received: from sitemail.everyone.net (dsnat [216.200.145.62])
	by omta03.mta.everyone.net (Postfix) with ESMTP id 34A2A4A2A2
	for <sip@ietf.org>; Fri, 24 May 2002 14:43:57 -0700 (PDT)
Received: by sitemail.everyone.net (Postfix, from userid 99)
	id 0842736F9; Fri, 24 May 2002 14:43:57 -0700 (PDT)
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Date: Fri, 24 May 2002 14:43:56 -0700 (PDT)
From: Kosta Koeman <kkoeman@techemail.com>
To: sip@ietf.org
Reply-To: kkoeman@techemail.com
X-Originating-Ip: [131.107.3.79]
Message-Id: <20020524214357.0842736F9@sitemail.everyone.net>
Content-Transfer-Encoding: 7bit
Subject: [Sip] bug in grammar
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Subtle bug in grammer.  Page 167 definition of rfc1123-date reads as

wkday "," date1 SP time SP "GMT"

should read

wkday "," SP date1 SP time SP "GMT"

Kosta

_____________________________________________________________
Are you a Techie? Get Your Free Tech Email Address Now! Visit http://www.TechEmail.com

_____________________________________________________________
Promote your group and strengthen ties to your members with email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag

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



From daemon@optimus.ietf.org  Fri May 24 23:56:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29815
	for <sip-archive@odin.ietf.org>; Fri, 24 May 2002 23:56:22 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA06692
	for sip-archive@odin.ietf.org; Fri, 24 May 2002 23:56:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05363;
	Fri, 24 May 2002 23:20:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA05332
	for <sip@optimus.ietf.org>; Fri, 24 May 2002 23:20:00 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28154
	for <sip@ietf.org>; Fri, 24 May 2002 23:19:39 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.26])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4P3L1YH023448;
	Fri, 24 May 2002 23:21:02 -0400 (EDT)
Message-ID: <3CEF02BE.6580CB9D@dynamicsoft.com>
Date: Fri, 24 May 2002 23:19:26 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: kkoeman@techemail.com
CC: sip@ietf.org
Subject: Re: [Sip] bug in grammar
References: <20020524214357.0842736F9@sitemail.everyone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Yes, we are aware of that one.

Thanks!

-Jonathan R.

Kosta Koeman wrote:
> 
> Subtle bug in grammer.  Page 167 definition of rfc1123-date reads as
> 
> wkday "," date1 SP time SP "GMT"
> 
> should read
> 
> wkday "," SP date1 SP time SP "GMT"
> 
> Kosta
> 
> _____________________________________________________________
> Are you a Techie? Get Your Free Tech Email Address Now! Visit
> http://www.TechEmail.com
> 
> _____________________________________________________________
> Promote your group and strengthen ties to your members with
> email@yourgroup.org by Everyone.net  http://www.everyone.net/?btn=tag
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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



From daemon@ns.ietf.org  Sat May 25 02:32:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14548
	for <sip-archive@odin.ietf.org>; Sat, 25 May 2002 02:32:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA22466
	for sip-archive@odin.ietf.org; Sat, 25 May 2002 02:32:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20174;
	Sat, 25 May 2002 02:03:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20145
	for <sip@optimus.ietf.org>; Sat, 25 May 2002 02:03:53 -0400 (EDT)
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09119
	for <sip@ietf.org>; Sat, 25 May 2002 02:03:30 -0400 (EDT)
Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206])
	by ganymede.or.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g4P63LE21733
	for <sip@ietf.org>; Sat, 25 May 2002 06:03:21 GMT
Received: from orsmsx26.jf.intel.com ([192.168.65.26])
 by orsmsxvs040.jf.intel.com (NAVGW 2.5.1.16) with SMTP id M2002052423113005394
 for <sip@ietf.org>; Fri, 24 May 2002 23:11:30 -0700
Received: by orsmsx26.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <LRCGQS7G>; Fri, 24 May 2002 23:03:21 -0700
Message-ID: <F1CE15E08172D4119247009027AE9D500D6B9D55@fmsmsx37.fm.intel.com>
From: "Krishnaswamy, Pavitra" <pavitra@trillium.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Fri, 24 May 2002 23:03:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Multicast Registrations
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

I have a question about multicast registrations. 

What is the exact purpose of a multicast registration? Is it only meant for
discovery of Registrars when a UA doesn't have this information or does it
have any other meaning/use? In a UA implementation, does the multicast
registration have to be refreshed periodically? If yes, won't it cause
traffic issues on the network (more so if the expires header for the
registration request is small). Would really appreciate any input on this
issue.

Thanks in advance,
pavitra



                               
Pavitra Krishnaswamy
Trillium, An Intel Company
12100 Wilshire Blvd.
Los Angeles, CA 90025
http://www.trillium.com
pavitra@trillium.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 daemon@ns.ietf.org  Sat May 25 09:32:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21265
	for <sip-archive@odin.ietf.org>; Sat, 25 May 2002 09:32:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA09303
	for sip-archive@odin.ietf.org; Sat, 25 May 2002 09:32:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08424;
	Sat, 25 May 2002 09:13:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08393
	for <sip@ns.ietf.org>; Sat, 25 May 2002 09:13:30 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21147
	for <sip@ietf.org>; Sat, 25 May 2002 09:13:08 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4PDDRmG009208;
	Sat, 25 May 2002 15:13:27 +0200 (MEST)
Received: from ericsson.com (ppp28.lmf.ericsson.se [131.160.102.28])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4PDDO4J002731;
	Sat, 25 May 2002 16:13:25 +0300 (EET DST)
Message-ID: <3CEF8DF9.F2B33CA3@ericsson.com>
Date: Sat, 25 May 2002 16:13:29 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Tan Ya-Ching ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
CC: sip@ietf.org
Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01
References: <5B4D0C5BA65ECA46969C1419122317E6E74DD9@mchh161e>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Ya-Ching:

Thanks a lot for your comments. See my answers inline.

/Miguel

Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
> Hi,
> 
> - Reading the draft for the first time, I must say that I was confused by
> the 4th
>   paragraph of the Section 2 which starts with "Another possible solution to
> the
>   problem is...". Up to this point the draft talks about the problem, with
> no
>   solution mentioned yet. With the "Another possible solution", I thought I
> had
>   a corrupted version of the draft with some paragraphs missing.
> 

<miguel>
Section 2 starts with a description of the problem in the first
paragraph. Paragraphs 2 and 3 in this section describe a possible solution
that does not work. Paragraphs 4 and 5 describe another possible solution
that does not work as well. That is why the 4th paragraph begins with 
"Another possible solution ...".
</miguel>

> - The next paragraph which starts with "The solution described above...",
> the
>   sentence "that some URIs may be automatically registered when the UA
>   registers some of its URIs" confused me further.
>

<miguel>
Maybe the following text is clearer:
"some URIs may be automatically registered when the UA registers a 
particular URI".
</miguel> 

> - Is the term "terminating ID" (of the current INVITE) defined somewhere ? I
> think
>   you mean "the destination (request-URI) of the request before it was
> replaced
>   by the contact address".

<miguel>
Yes, you are right. I think if I replace "terminating ID" by "intended 
destination URI" the sentence is clearer. It will read:

"... so that the UAC is not aware of the intended destination URI in 
the current INVITE."
</miguel>

> 
> - In the example, the sentence above the mesage F2 starts with
>   "A user also...", do you actually mean "The user also..." ?
>

<miguel>
Certainly is "The user also ..."
</miguel> 


> - The last paragraph of Section 2 :
>   "... the proxy that is serving the user..." should be made clearer,
> perhaps with
>   "the proxy that is responsible for the home domain (as defined in RFC
> 3261) of
>   the user" ? Also, please add a "header" after the P-Called-Party-ID in the
> same
>   sentence.

<miguel>
ok. Done!!!
</miguel>

> 
> - Section 3
>   "1. The UA registers to his proxy with one or more SIP URIs". Does it have
> to be
>    SIP URIs or can it be "SIP or SIPS URIs" ? I assume you mean here that
> the
>    UA registers one or more address-of-record.

<miguel>
The important thing here is that the UAC registers at least one SIP or SIPS
URI to his proxy. It is not relevant whether there are one or more address-of-
record registered. What I want to say is that the user may register more
than one SIP or SIPS URI.
</miguel>

>   "2. The proxy receives an INVITE destined to a user's ID" means :
>   "2. An INVITE arrives at a proxy which is responsible for the domain of
> the
>        Request-URI".

<miguel>
better... However we are missing the connection between the proxy and the
registrar. Perhaps the sentence should read "an INVITE destined for the user
arrives at a proxy in the domain where the user is registered. The proxy 
contacts the registrar to find the location of the user."
</miguel>


> 
>   Come to think of it, these applicability statements apply to all SIP
> requests in
>   general. It is normal for a UA to register to his proxy with at least one
> address-
>   of-record, and some proxy always receives an INVITE destined to a user'
> ID.

<miguel>
Not necessarily. Registration is an optional procedure in SIP, although 
quite common. Without registration this P- header has no sense at all.
</miguel>

>   I do not see how these statements meet the requirement of [3], which
> states :
> 
>   "An applicability statement in the Informational RFC MUST
>    clearly document the useful scope of the proposal, and explain
>    its limitations and why it is not suitable for the general use
>    of SIP in the Internet."

<miguel>
My effort was to scope as much as possible this header. It is suitable
for the general use of SIP in the Internet, so I have nothing else to
say.
</miguel>

> 
> - Section 4 2nd paragraph
>   o This paragraph seems to imply that any SIP proxy can insert the
>      P-Call-Party-ID header field.

<miguel>
fixed.
</miguel>

>   o The term "standalone method" is not defined in SIP RFC.

<miguel>
I meant requests that do not create a dialog, such a MESSAGE.
But I need to differentiate from requests that are sent within
a dialog (e.g. INFO).
I'll fix it somehow, but I think that the term standalone, 
although not define in RFC 3261, is understandable by the
reader familiar with SIP.
</miguel>

>   o INVITE is a method that initiates a dialog so it cannot be "INVITE or
>     method that intiates a dialog".

<miguel>
fixed
</miguel>

> 
> - Section 5
>   The sentence "The allowable usage of headers..." is repeated. The 3rd
>   paragraph should be completely deleted.
> 

<miguel>
Ooops, I forgot to delete this paragraph when I replaced it by the next 
paragra. Thanks a lot. Fixed
</miguel>

> - Section 6.2
>   First paragraph
>   o The term "standalone method" is not defined in SIP RFC.
>   o INVITE is a method that initiates a dialog so it cannot be "INVITE or
>     method that intiates a dialog".
>   o "...contents Request-URI" => "...contents of the Request-URI..."
> 
>   Second paragraph
>   o "...the proxy who..." => "...the proxy which..."
> 

<miguel>
All fixed. You will see the changes in the next version.
</miguel>

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

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@ns.ietf.org  Sat May 25 09:42:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21607
	for <sip-archive@odin.ietf.org>; Sat, 25 May 2002 09:42:09 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA09535
	for sip-archive@odin.ietf.org; Sat, 25 May 2002 09:42:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08463;
	Sat, 25 May 2002 09:14:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA08432
	for <sip@ns.ietf.org>; Sat, 25 May 2002 09:14:06 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21151
	for <sip@ietf.org>; Sat, 25 May 2002 09:13:44 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4PDE56n025796;
	Sat, 25 May 2002 15:14:05 +0200 (MEST)
Received: from ericsson.com (ppp28.lmf.ericsson.se [131.160.102.28])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4PDE24J002740;
	Sat, 25 May 2002 16:14:03 +0300 (EET DST)
Message-ID: <3CEF8E1F.41467F09@ericsson.com>
Date: Sat, 25 May 2002 16:14:07 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Tan Ya-Ching ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
CC: sip@ietf.org
Subject: Re: [Sip] Comments on draft-garcia-sip-visited-network-id-01
References: <5B4D0C5BA65ECA46969C1419122317E6E74DDA@mchh161e>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Ya-Ching:

Thanks a lot for your comments. See my answers inline.

/Miguel

Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
> Hi,
> 
>  - General
>    The term 'standalone request'  or 'standalone transaction
>    request' is used throughout the document. Please define
>    what it means.

<miguel>
Yes, I will apply a similar treatment as for the P-Called-Party-ID
</miguel>

> 
>  - 3rd paragraph of Section 1
>    "... it seems sensitive..." should be "... it seems sensible..."
> 
<miguel>
done
</miguel>

>  - Section 2, point 3 "There is not requirement that..." should
>    be "There is no requirement that ...", and at the end of the
>    sentence, "in this memo" should be "in this document".

<miguel>
I have no problems with the change, but many RFCs refer to "this
document" as "this memo".
</miguel>
> 
> - Section 4
>   Please delete the 1st sentence "The P-Visited-Network-ID
>   is an extension of a SIP header", or replace it with "This
>   specification defines a new header field.
> 

<miguel>
Replaced
</miguel>

> - 1st paragraph on page 4
>   "..., a SIP node may insert a new P-Visited-Network-ID header,
>   if there was already one present with different contents" is
>   misleading. I think you meant :
>   "..., a proxy MAY insert a new P-Visited-Network-ID header
>   if the request does not contain any P-Visited-Network-ID header
>   with the same network identifier as its own network identifier".
> 
>   Delete the "a vairous" in "...a various different administrative
>   domains"
> 

<miguel>
fine
</miguel>

> - The addition to Table 2 in Section 4
>   A "r" should be added to the "ad" under proxy. Proxies must
>   be able to read this header.
> 

<miguel> Ummm... not sure. If a proxy decides to encrypt this 
header, so that only the registrar or proxy at home is able to
read it, it will not make any negative effect to other proxies
in the path. The only negative effect is that these proxies in
the middle will not be able to read the contents, so they will
not know if the same visited network ID was already present or
not. But it does not introduce any problem. 
</miguel>

> - Section 5.1
>   "The UA SHOULD NOT insert" should be "MUST NOT insert".
>   I think the result can be disastrous if a UA inserts one.
> 

<miguel>
Yes, I agree with you, it should be a MUST NOT.
</miguel>

> - Section 5.2
>   Replace "the contents of a provisioned string" with just "a text
>   string" and delete the "at the user's home domain" at the end.
>   Otherwise it reads like "identifies ...the proxy is operating
>   at the user's home network", where it is not.
> 

<miguel>
What I wanted to express, is a scenario where a proxy in a visited
network is using different strings to identify his own network
at different home networks. So, for example, proxy P1 receives
a request addressed to network N1; P1 inserts VNID1. The same proxy
P1 receives a request addressed to network N2; it may decide to
insert VNID2. This VNID is known between both networks, so from
the point of view of the protocol I don't see why we should limit
it here.
</miguel>
 
> - 10.2
>   draft-sipping-garcia-3gpp-req-03 should be
>   draft-garcia-sipping-3gpp-req-03 instead. This same error
>   is also in the called party id draft.

<miguel>
Ooops... Fixed.
</miguel>


> 
> Regards,
> Ya-Ching

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Mon May 27 04:39:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14207
	for <sip-archive@odin.ietf.org>; Mon, 27 May 2002 04:39:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA27929
	for sip-archive@odin.ietf.org; Mon, 27 May 2002 04:40:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26679;
	Mon, 27 May 2002 04:13:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA26647
	for <sip@optimus.ietf.org>; Mon, 27 May 2002 04:13:07 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13849
	for <sip@ietf.org>; Mon, 27 May 2002 04:12:44 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA00013;
	Mon, 27 May 2002 10:12:51 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA23818;
	Mon, 27 May 2002 10:13:05 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LL4YTWVS>; Mon, 27 May 2002 10:13:12 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Comments on draft-garcia-sip-called-party-id-01
Date: Mon, 27 May 2002 10:12:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi Miguel,

| <miguel>
| Maybe the following text is clearer:
| "some URIs may be automatically registered when the UA registers a 
| particular URI".
| </miguel> 

A REGISTER is used to create a binding between an address-of-record AOR (or
public address) and a contact address. One may use a new registration to
bind more contact addresses to an AOR. It is also possible or have more than
one AOR bound to the same contact address (more than one user can be
registered on a single device). So it is not clear to me in your sentence
above what URIs you are talking about - public addresses or contact
addresses ?
| 
| 
| <miguel>
| The important thing here is that the UAC registers at least 
| one SIP or SIPS
| URI to his proxy. It is not relevant whether there are one or 
| more address-of-
| record registered. What I want to say is that the user may 
| register more
| than one SIP or SIPS URI.
| </miguel>

Same comment as above. You cannot just say that a user register more than
one SIP or SIPS URI. I think the point of the whole draft is that a user can
have more than one address-of-record (public address) -
sip:user1-business@example.com and sip:user1-private@example.com. These
address-of-record's are bound to the same device. When he gets a call, the
Request-URI is always replaced by his contact/device address and so he
cannot tell which address-of-record the caller has used to call him.

| >   I do not see how these statements meet the requirement of 
| [3], which
| > states :
| > 
| >   "An applicability statement in the Informational RFC MUST
| >    clearly document the useful scope of the proposal, and explain
| >    its limitations and why it is not suitable for the general use
| >    of SIP in the Internet."
| 
| <miguel>
| My effort was to scope as much as possible this header. It is suitable
| for the general use of SIP in the Internet, so I have nothing else to
| say.
| </miguel>

If it is suitable for the general use, why a P-header ?


| >   o The term "standalone method" is not defined in SIP RFC.
| 
| <miguel>
| I'll fix it somehow, but I think that the term standalone, 
| although not define in RFC 3261, is understandable by the
| reader familiar with SIP.
| </miguel>

RFC 3261 even defines terms such as "Message", "Parallel Search". One simply
can't start using a new term like "standalone request" or "standalone
transaction request" and assume that it is 'understandable by the reader
familiar with SIP'.


Regards,
Ya-Ching
 

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



From daemon@optimus.ietf.org  Mon May 27 04:58:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14659
	for <sip-archive@odin.ietf.org>; Mon, 27 May 2002 04:58:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA29885
	for sip-archive@odin.ietf.org; Mon, 27 May 2002 04:59:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28127;
	Mon, 27 May 2002 04:42:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA28096
	for <sip@optimus.ietf.org>; Mon, 27 May 2002 04:42:51 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14244
	for <sip@ietf.org>; Mon, 27 May 2002 04:42:28 -0400 (EDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id KAA03049;
	Mon, 27 May 2002 10:42:36 +0200 (MET DST)
Received: from mchh159e.mch4.siemens.de ([139.21.130.171])
	by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id KAA04861;
	Mon, 27 May 2002 10:42:50 +0200 (MET DST)
Received: by mchh159e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LL4YTW6Y>; Mon, 27 May 2002 10:42:57 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DDD@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Comments on draft-garcia-sip-visited-network-id-01
Date: Mon, 27 May 2002 10:42:42 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi Miguel,

| > - The addition to Table 2 in Section 4
| >   A "r" should be added to the "ad" under proxy. Proxies must
| >   be able to read this header.
| > 
| 
| <miguel> Ummm... not sure. If a proxy decides to encrypt this 
| header, so that only the registrar or proxy at home is able to
| read it, it will not make any negative effect to other proxies
| in the path. The only negative effect is that these proxies in
| the middle will not be able to read the contents, so they will
| not know if the same visited network ID was already present or
| not. But it does not introduce any problem. 
| </miguel>

If P-Visited-Network_ID header cannot be read by proxy, I fail to see the
point of this header.

If the draft states that "... a SIP node (I think you mean proxy here) may
insert a new P-Visited-Network-ID header, if there was already one present
with different contents...", then you have to state what happens if the
content is encrypted and the proxy cannot see the contents. You can't just
say 'But it does not introduce any problem'.

| 
| <miguel>
| What I wanted to express, is a scenario where a proxy in a visited
| network is using different strings to identify his own network
| at different home networks. So, for example, proxy P1 receives
| a request addressed to network N1; P1 inserts VNID1. The same proxy
| P1 receives a request addressed to network N2; it may decide to
| insert VNID2. This VNID is known between both networks, so from
| the point of view of the protocol I don't see why we should limit
| it here.
| </miguel>

OK. Now I get it.

Regards,
Ya-Ching

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



From daemon@optimus.ietf.org  Mon May 27 05:41:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15393
	for <sip-archive@odin.ietf.org>; Mon, 27 May 2002 05:41:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id FAA03615
	for sip-archive@odin.ietf.org; Mon, 27 May 2002 05:42:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02383;
	Mon, 27 May 2002 05:28:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02353
	for <sip@optimus.ietf.org>; Mon, 27 May 2002 05:28:12 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15221
	for <sip@ietf.org>; Mon, 27 May 2002 05:27:48 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4R9S16n014981;
	Mon, 27 May 2002 11:28:03 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4R9S0gu024318;
	Mon, 27 May 2002 12:28:00 +0300 (EET DST)
Message-ID: <3CF1FC20.3CFDAEE6@ericsson.com>
Date: Mon, 27 May 2002 12:28:00 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Tan Ya-Ching ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
CC: sip@ietf.org
Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01
References: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Ya-Ching:

Comments below

Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
> Hi Miguel,
> 
> | <miguel>
> | Maybe the following text is clearer:
> | "some URIs may be automatically registered when the UA registers a
> | particular URI".
> | </miguel>
> 
> A REGISTER is used to create a binding between an address-of-record AOR (or
> public address) and a contact address. One may use a new registration to
> bind more contact addresses to an AOR. It is also possible or have more than
> one AOR bound to the same contact address (more than one user can be
> registered on a single device). So it is not clear to me in your sentence
> above what URIs you are talking about - public addresses or contact
> addresses ?

<miguel>
Reading again the text, I agree with you, it is not clear at all. The case I
refer is when an application server registers other address-of-record URIs
pointing to the same contact address. I will clarify the terminology in the
draft.
</miguel>

> |
> |
> | <miguel>
> | The important thing here is that the UAC registers at least
> | one SIP or SIPS
> | URI to his proxy. It is not relevant whether there are one or
> | more address-of-
> | record registered. What I want to say is that the user may
> | register more
> | than one SIP or SIPS URI.
> | </miguel>
> 
> Same comment as above. You cannot just say that a user register more than
> one SIP or SIPS URI. I think the point of the whole draft is that a user can
> have more than one address-of-record (public address) -
> sip:user1-business@example.com and sip:user1-private@example.com. These
> address-of-record's are bound to the same device. When he gets a call, the
> Request-URI is always replaced by his contact/device address and so he
> cannot tell which address-of-record the caller has used to call him.

<miguel> 
yes, I agree with you
</miguel>

> 
> | >   I do not see how these statements meet the requirement of
> | [3], which
> | > states :
> | >
> | >   "An applicability statement in the Informational RFC MUST
> | >    clearly document the useful scope of the proposal, and explain
> | >    its limitations and why it is not suitable for the general use
> | >    of SIP in the Internet."
> |
> | <miguel>
> | My effort was to scope as much as possible this header. It is suitable
> | for the general use of SIP in the Internet, so I have nothing else to
> | say.
> | </miguel>
> 
> If it is suitable for the general use, why a P-header ?

<miguel>
Because so far nobody else has the requirement as we expressed.
That's why we are going for a P- header. But the extension itself
is not restricted to 3GPP. It is generally applicable to the Internet.
</miguel>

> 
> | >   o The term "standalone method" is not defined in SIP RFC.
> |
> | <miguel>
> | I'll fix it somehow, but I think that the term standalone,
> | although not define in RFC 3261, is understandable by the
> | reader familiar with SIP.
> | </miguel>
> 
> RFC 3261 even defines terms such as "Message", "Parallel Search". One simply
> can't start using a new term like "standalone request" or "standalone
> transaction request" and assume that it is 'understandable by the reader
> familiar with SIP'.
> 

<miguel>Yes, I understand your comment. I will do my best to make it
clear what it means in the next version.
</miguel>

Thanks for your comments.

/miguel


> Regards,
> Ya-Ching
> 

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Mon May 27 19:31:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26064
	for <sip-archive@odin.ietf.org>; Mon, 27 May 2002 19:31:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA13255
	for sip-archive@odin.ietf.org; Mon, 27 May 2002 19:31:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12468;
	Mon, 27 May 2002 19:14:54 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12437
	for <sip@optimus.ietf.org>; Mon, 27 May 2002 19:14:51 -0400 (EDT)
Received: from dsl-64-192-31-101.telocity.com (dsl-64-192-31-101.telocity.com [64.192.31.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25970
	for <sip@ietf.org>; Mon, 27 May 2002 19:14:27 -0400 (EDT)
Received: from keyser1.dsl-64-192-31-101.telocity.com ([192.168.0.1])
          by dsl-64-192-31-101.telocity.com (JAMES SMTP Server 2.0a2) with SMTP ID 4
          for <sip@ietf.org>;
          Mon, 27 May 2002 19:14:10 -0400
Received: from jeff (unverified [192.168.0.18]) by KEYSER1.dsl-64-192-31-101.telocity.com
 (EMWAC SMTPRS 0.83) with SMTP id <B0000011188@KEYSER1.dsl-64-192-31-101.telocity.com>;
 Mon, 27 May 2002 19:13:35 -0400
From: "Jeff Keyser" <JKeyser@telocity.com>
To: "SIP Mailing List \(E-mail\)" <sip@ietf.org>
Date: Mon, 27 May 2002 19:13:33 -0400
Message-ID: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 7bit
Subject: [Sip] Comment on draft-ietf-sip-rfc2543bis-09
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I apologize if this is not the correct place for this comment.  If this is
not, please let me know where I should direct this.

I am working with draft-ietf-sip-rfc2543bis-09 to write a SIP client, and
the INVITE transactions of section 17 don't make sense to me as written.
For both client and server INVITE transactions in the "Proceeding" state
(and "Calling" state for client transactions), if a new response status code
is 300-699, the transaction changes to the "Completed" state; and, if a new
response status code is 2xx, the transaction changes to the "Terminated"
state.  The state diagrams show this same logic.

I assume that this is supposed to be the other way around, since the
"Completed" state is used the handle the ACK request of a connected 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 daemon@optimus.ietf.org  Mon May 27 21:20:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27026
	for <sip-archive@odin.ietf.org>; Mon, 27 May 2002 21:20:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA18099
	for sip-archive@odin.ietf.org; Mon, 27 May 2002 21:20:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17172;
	Mon, 27 May 2002 21:01:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17146
	for <sip@optimus.ietf.org>; Mon, 27 May 2002 21:01:09 -0400 (EDT)
Received: from uni02mr.unity.ncsu.edu (uni02mr.unity.ncsu.edu [152.1.1.165])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26781
	for <sip@ietf.org>; Mon, 27 May 2002 21:00:47 -0400 (EDT)
Received: from viking (viking.ecew2k.ncsu.edu [152.1.60.116])
	by uni02mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with SMTP id g4S11Al03631;
	Mon, 27 May 2002 21:01:10 -0400 (EDT)
Message-ID: <389c01c205e3$273eb010$743c0198@ecew2k.ncsu.edu>
From: "Prabhas Sinha" <prsinha@unity.ncsu.edu>
To: "Jeff Keyser" <JKeyser@telocity.com>,
        "SIP Mailing List \(E-mail\)" <sip@ietf.org>
References: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com>
Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09
Date: Mon, 27 May 2002 21:01:09 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Thanks for bringing this up Jeff. I too had asked this question some time
back to Vijay Gurbani.
Even I am waiting to get some clarifications on it if I didnt understand the
model.

Prabhas

----- Original Message -----
From: "Jeff Keyser" <JKeyser@telocity.com>
To: "SIP Mailing List (E-mail)" <sip@ietf.org>
Sent: Monday, May 27, 2002 7:13 PM
Subject: [Sip] Comment on draft-ietf-sip-rfc2543bis-09


> I apologize if this is not the correct place for this comment.  If this is
> not, please let me know where I should direct this.
>
> I am working with draft-ietf-sip-rfc2543bis-09 to write a SIP client, and
> the INVITE transactions of section 17 don't make sense to me as written.
> For both client and server INVITE transactions in the "Proceeding" state
> (and "Calling" state for client transactions), if a new response status
code
> is 300-699, the transaction changes to the "Completed" state; and, if a
new
> response status code is 2xx, the transaction changes to the "Terminated"
> state.  The state diagrams show this same logic.
>
> I assume that this is supposed to be the other way around, since the
> "Completed" state is used the handle the ACK request of a connected 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
>


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



From daemon@optimus.ietf.org  Tue May 28 02:00:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01515
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 02:00:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA11840
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 02:00:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10159;
	Tue, 28 May 2002 01:38:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10122
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 01:38:26 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00371
	for <sip@ietf.org>; Tue, 28 May 2002 01:38:00 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4S5bsHs024939;
	Mon, 27 May 2002 22:37:54 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ACZ93037;
	Mon, 27 May 2002 22:38:04 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: <sip@ietf.org>
Date: Mon, 27 May 2002 22:38:43 -0700
Message-ID: <DLEHICEBMNEIPCACNLPCEEFHCDAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-ietf-sip-asserted-identity-00
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Jon, Mark, and I have put together a new version of the asserted identity
draft - until it arrives in the archives, you can find it at:

http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-00.html
http://www.cs.ubc.ca/~jennings/draft-ietf-sip-asserted-identity-00.txt

Cullen


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



From daemon@optimus.ietf.org  Tue May 28 02:03:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04999
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 02:03:10 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA12130
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 02:03:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10441;
	Tue, 28 May 2002 01:44:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA10410
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 01:44:47 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00518
	for <sip@ietf.org>; Tue, 28 May 2002 01:44:22 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4S5joYH024687;
	Tue, 28 May 2002 01:45:51 -0400 (EDT)
Message-ID: <3CF3192F.CCB8076F@dynamicsoft.com>
Date: Tue, 28 May 2002 01:44:15 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Keyser <JKeyser@telocity.com>
CC: "SIP Mailing List (E-mail)" <sip@ietf.org>
Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09
References: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

inline.

Jeff Keyser wrote:
> 
> I apologize if this is not the correct place for this comment.  If this
> is
> not, please let me know where I should direct this.
> 
> I am working with draft-ietf-sip-rfc2543bis-09 to write a SIP client,
> and
> the INVITE transactions of section 17 don't make sense to me as written.
> For both client and server INVITE transactions in the "Proceeding" state
> (and "Calling" state for client transactions), if a new response status
> code
> is 300-699, the transaction changes to the "Completed" state; and, if a
> new
> response status code is 2xx, the transaction changes to the "Terminated"
> state.  The state diagrams show this same logic.
> 
> I assume that this is supposed to be the other way around, since the
> "Completed" state is used the handle the ACK request of a connected
> call.

No, it is correct as written. 

The reason is that this state machine represents the *transaction*
state. The transaction state machine is responsible for request/response
correlation, retransmissions, and so on. It is NOT responsible for the
management of the call state. When a 2xx is received, the transaction is
complete. There is an ACK, but this ACK constitutes a separate
transaction. Correlation of the ACK with the 2xx is done by the UAS at a
higher layer, not by the transaction machines. In contrast, for non-2xx
final responses, the ACK is part of the same transaction, and so the
state machine must stick around to handle that. 

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Tue May 28 02:40:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09613
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 02:40:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA14275
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 02:40:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12657;
	Tue, 28 May 2002 02:15:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12627
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 02:15:13 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09399
	for <sip@ietf.org>; Tue, 28 May 2002 02:14:50 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4S6GIYH024701
	for <sip@ietf.org>; Tue, 28 May 2002 02:16:18 -0400 (EDT)
Message-ID: <3CF32051.287C0D20@dynamicsoft.com>
Date: Tue, 28 May 2002 02:14:41 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] new I-D for registration event package
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

I've just submitted draft-rosenberg-sip-reg-event to the archives. Until
it appears you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-reg-event-00.txt

This draft is an attempt to generalize the registration event package
defined in:

http://www.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-01.txt

I believe there are a lot of valuable applications for a registration
event package, and therefore, having a generalized version seems like a
good thing. There is nothing radically different between the two drafts.
The main difference is that mine defines a specific state machine for
registration events, and defines an XML document format to specifically
convey information about changes to that machine. It doesn't reuse the
presence document format, as the beckmann draft does. My draft does
appear to meet the 3gpp requirements. 

The key decision point for the group is whether to move forward with
draft-rosenberg-sip-reg-event (as a sipwg draft) or
draft-beckmann-sip-reg-event. Unfortunately, the timeline doesn't change
in either case, since something is needed for 3gpp in quite short order.
In some private email conversations, Mark and Georg indicated support
for going with a generalized version, but I will let them speak for
themselves.

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

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



From daemon@optimus.ietf.org  Tue May 28 03:28:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10088
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 03:28:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA16949
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 03:28:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16037;
	Tue, 28 May 2002 03:06:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15998
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 03:06:50 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09912
	for <sip@ietf.org>; Tue, 28 May 2002 03:06:26 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.184])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4S77eYH024722;
	Tue, 28 May 2002 03:07:41 -0400 (EDT)
Message-ID: <3CF32C5C.EBB59A71@dynamicsoft.com>
Date: Tue, 28 May 2002 03:06:04 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com,
        Miguel Garcia <Miguel.A.Garcia@ericsson.com>
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Dean Willis wrote:
> 
> I'd like to request feedback on the expert review of
> draft-garcia-sip-associated URI:
> 
> Option:
> 
>    Yeah
>    Nay
>    Or Needs More Work
> 

I think the draft is generally OK, but needs a bit more work. My main
area of concern is the applicability statement. It really just repeats
the semantics of the header. Really, the scope of applicability is more
something like this:

"This specification is applicable in SIP networks where the SIP provider
is attempting to restrict the set of identities that a user can claim
(in headers like the From field) in requests that it generates. It
furthermore assumes that the provider knows the entire set of identities
that a user can legitimately claim, and that the user is willing to
restrict its claimed identities to that set. In normal SIP usage, the
>From field is explicitly an end-user specified field. Effectively, this
specification attempts to make it an end-user-specified and provider
approved field.

This specification also assumes a closed network model. The restriction
of the From field (and other fields) to be among the list of approved
values is enforced by a proxy in the domain of the caller. The
specification provides no way to indicate or verify to downstream
proxies or to the UAS that these fields have been limited in scope. As a
result, this specification will only be useful in closed networks where
elements know through configuration or administration that the fields
have been restricted."


I also think the security considerations section deserves some more
attention. For one thing, I think that the information in this header is
very sensitive. It exposes many additional identities for a user, which
they might not otherwise want to divulge to everyone. For example, if
the URI I register is sip:jdr@example.com, and everyone also has a valid
URI which is their full name - sip:jonathan.rosenberg@example.com -
eavesdropping the registrations will allow someone to learn my name. The
draft alludes to this problem in the second paragraph, but it needs to
strengthen the discussion and give specific examples like the one above.

On an unrelated note, I must admit being baffled about why this is
useful in a subscribe response. It seems like the associated URI are
closely related to registrations, not subscriptions.





Some minor points:

1. the syntax does not permit an empty value for the P-Associated-URI.
What happens if there are no associated URI? If you simply omit the
header altogetrher, how does the UA distinguish the case where the
registrar doesn't support the extension, as opposed to the registrar has
no associated URIs?

2. Is there an implicit assumption that the registrar will register the
associated URI? I believe this is true in the 3gpp case. A UA probably
needs to know whether they have been registered or not. I would not want
to put a URI into a Reply-To header unless I knew it was a valid URI for
receiving incoming calls....

3. you write:

> The registrar inserts the P-Associated-URI header into the 200 OK
>    response to a REGISTER request. The header is populated with a list of
>    URIs that are associated to the registered URI.

probably "address-of-record" is better than "registered URI" in the
above.

4. you write:

> populate the From header value, or any other SIP header value that
>    provides information of the identity of the calling party, in a
>    subsequent dialog.

s/subsequent dialog/subsequent request

5. you should probably have an explicit definition of associated URI.

6. you write:

> 5.3 Procedures at the proxy
> 
>    This memo does not define any procedures at the proxy.
> 

Well, presumably some proxy will enforce the list of associated-URI, and
reject requests that have a value in the From field not amongst the
allowed set? Is there a new response code for that?


Thanks,
Jonathan R.



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

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



From daemon@optimus.ietf.org  Tue May 28 03:45:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10277
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 03:45:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA18394
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 03:45:34 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16665;
	Tue, 28 May 2002 03:22:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16634
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 03:22:40 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10053
	for <sip@ietf.org>; Tue, 28 May 2002 03:22:16 -0400 (EDT)
Received: from jh by lohi.eng.song.fi with local (Exim 3.34 #1 (Debian))
	id 17CbJQ-0006SW-00; Tue, 28 May 2002 10:22:32 +0300
From: Juha Heinanen <jh@lohi.eng.song.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15603.12344.116679.526241@lohi.eng.song.fi>
Date: Tue, 28 May 2002 10:22:32 +0300
To: "Cullen Jennings" <fluffy@cisco.com>
Cc: <sip@ietf.org>
Subject: [Sip] draft-ietf-sip-asserted-identity-00
In-Reply-To: <DLEHICEBMNEIPCACNLPCEEFHCDAA.fluffy@cisco.com>
References: <DLEHICEBMNEIPCACNLPCEEFHCDAA.fluffy@cisco.com>
X-Mailer: VM 6.97 under Emacs 20.7.2
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

once again:

the term "hint" is not a good one.  if user adds the a-i, then the
network MUST respect it or reject the request.  the network MUST not
override the a-i and pick one of the identities on its own.  for
example, the user may have misspelled the its uri in the a-i.

also, the text should say that in case from is anonymous the user MUST
insert the a-i header if it has multiple identities, because otherwise
the network cannot know which identity the user wants to use.

finally, for backwards compatibility, if from is not anonymous and the
user has multiple identities, then from uri can serve as the purpose of
a-i.

-- 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 daemon@optimus.ietf.org  Tue May 28 04:19:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10653
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 04:19:06 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA20622
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 04:19:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18721;
	Tue, 28 May 2002 03:48:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA18683
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 03:48:12 -0400 (EDT)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10369
	for <sip@ietf.org>; Tue, 28 May 2002 03:47:47 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4S7lec30863
	for <sip@ietf.org>; Tue, 28 May 2002 03:47:41 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25Z4T84>; Tue, 28 May 2002 02:47:35 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870367@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Tue, 28 May 2002 02:47:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] draft-ietf-sip-privacy-general-00
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The following is a revision of my draft about privacy in SIP. Comments
welcome, as always.

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.txt

Jon Peterson
NeuStar, Inc.

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



From daemon@optimus.ietf.org  Tue May 28 06:42:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12048
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 06:42:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA29572
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 06:43:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27997;
	Tue, 28 May 2002 06:19:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27968
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 06:19:55 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11790
	for <sip@ietf.org>; Tue, 28 May 2002 06:19:29 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4SAJqmG013243
	for <sip@ietf.org>; Tue, 28 May 2002 12:19:52 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4SAJqgu011142
	for <sip@ietf.org>; Tue, 28 May 2002 13:19:52 +0300 (EET DST)
Message-ID: <3CF359C6.126B596F@lmf.ericsson.se>
Date: Tue, 28 May 2002 13:19:50 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] New version of the compression draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

I have just submitted a new version of the SIP compression draft:

http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sip-compression-01.txt

I have included an example and fixed a couple of things based on the
feedback I have received so far.

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@optimus.ietf.org  Tue May 28 06:43:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12069
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 06:43:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA29587
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 06:43:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27864;
	Tue, 28 May 2002 06:18:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27833
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 06:18:36 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11780
	for <sip@ietf.org>; Tue, 28 May 2002 06:18:10 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4SAIK6n024727;
	Tue, 28 May 2002 12:18:20 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4SAIJgu011121;
	Tue, 28 May 2002 13:18:19 +0300 (EET DST)
Message-ID: <3CF3596B.13D72E7@ericsson.com>
Date: Tue, 28 May 2002 13:18:19 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2> <3CF32C5C.EBB59A71@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Jonathan:

Thanks for your comments. See my answers inline.

Jonathan Rosenberg wrote:
> 
> Dean Willis wrote:
> >
> > I'd like to request feedback on the expert review of
> > draft-garcia-sip-associated URI:
> >
> > Option:
> >
> >    Yeah
> >    Nay
> >    Or Needs More Work
> >
> 
> I think the draft is generally OK, but needs a bit more work. My main
> area of concern is the applicability statement. It really just repeats
> the semantics of the header. Really, the scope of applicability is more
> something like this:
> 
> "This specification is applicable in SIP networks where the SIP provider
> is attempting to restrict the set of identities that a user can claim
> (in headers like the From field) in requests that it generates. It
> furthermore assumes that the provider knows the entire set of identities
> that a user can legitimately claim, and that the user is willing to
> restrict its claimed identities to that set. In normal SIP usage, the
> From field is explicitly an end-user specified field. Effectively, this
> specification attempts to make it an end-user-specified and provider
> approved field.
> 
> This specification also assumes a closed network model. The restriction
> of the From field (and other fields) to be among the list of approved
> values is enforced by a proxy in the domain of the caller. The
> specification provides no way to indicate or verify to downstream
> proxies or to the UAS that these fields have been limited in scope. As a
> result, this specification will only be useful in closed networks where
> elements know through configuration or administration that the fields
> have been restricted."

So far so good.

> I also think the security considerations section deserves some more
> attention. For one thing, I think that the information in this header is
> very sensitive. It exposes many additional identities for a user, which
> they might not otherwise want to divulge to everyone. For example, if
> the URI I register is sip:jdr@example.com, and everyone also has a valid
> URI which is their full name - sip:jonathan.rosenberg@example.com -
> eavesdropping the registrations will allow someone to learn my name. The
> draft alludes to this problem in the second paragraph, but it needs to
> strengthen the discussion and give specific examples like the one above.

I will add this discussion to the security considerations.

> On an unrelated note, I must admit being baffled about why this is
> useful in a subscribe response. It seems like the associated URI are
> closely related to registrations, not subscriptions.

And in fact, the only usage in 3GPP is in registrations. But I got
some comments that this may be useful in subscriptions as well. If nobody
shouts, I will remove the usage of the header in subscriptions and restrict
the scope to REGISTER only.

> 
> Some minor points:
> 
> 1. the syntax does not permit an empty value for the P-Associated-URI.
> What happens if there are no associated URI? If you simply omit the
> header altogetrher, how does the UA distinguish the case where the
> registrar doesn't support the extension, as opposed to the registrar has
> no associated URIs?

Do we need to make a distinction between both cases? Either case, the
user knows that no other identities are associated by the registrar,
and therefore, explicit actions (e.g., REGISTER) has to be taken by
the UAC.

I am open to include an empty header, if it is needed. But I thought
the consequences at the UAC are the same.


> 2. Is there an implicit assumption that the registrar will register the
> associated URI? I believe this is true in the 3gpp case. A UA probably
> needs to know whether they have been registered or not. I would not want
> to put a URI into a Reply-To header unless I knew it was a valid URI for
> receiving incoming calls....

No, this is not the case. The "reg" event will provide such information.
But the semantics of this header is just to provide a set of IDs that the
user has associated to the address-of-record. They may or may not be registered,
the user will know this information by other means (subscription to the 
registration event package). The user knows that he can initiate registration
of any of the returned IDs, or it can populate the From with any of those
IDs as well. That's it.

We can clarify this if it is not clear enough.



> 3. you write:
> 
> > The registrar inserts the P-Associated-URI header into the 200 OK
> >    response to a REGISTER request. The header is populated with a list of
> >    URIs that are associated to the registered URI.
> 
> probably "address-of-record" is better than "registered URI" in the
> above.

Sure.


> 
> 4. you write:
> 
> > populate the From header value, or any other SIP header value that
> >    provides information of the identity of the calling party, in a
> >    subsequent dialog.
> 
> s/subsequent dialog/subsequent request
> 

Done.

> 5. you should probably have an explicit definition of associated URI.

yeap. I'll add that.

 
> 6. you write:
> 
> > 5.3 Procedures at the proxy
> >
> >    This memo does not define any procedures at the proxy.
> >
> 
> Well, presumably some proxy will enforce the list of associated-URI, and
> reject requests that have a value in the From field not amongst the
> allowed set? Is there a new response code for that?

Yes, the proxy will send a 403 Forbidden. However, I don't think this is 
part of the scope of this I-D. I understand that the title "Procedures at
the proxy" are procedures related to the extension (the header in this case).
The idea in this I-D is to convey to the UA the list of URIs that he can use 
in subsequent requests, not how to police them. Therefore, there are not
procedures at the proxy related to the P-Associated-URI header.

Thanks a lot for your comments,

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

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@optimus.ietf.org  Tue May 28 06:48:55 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12167
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 06:48:55 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA29951
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 06:49:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27795;
	Tue, 28 May 2002 06:17:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA27772
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 06:17:40 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11777
	for <sip@ietf.org>; Tue, 28 May 2002 06:17:14 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4SAHYmG012448;
	Tue, 28 May 2002 12:17:35 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4SAHYgu011097;
	Tue, 28 May 2002 13:17:34 +0300 (EET DST)
Message-ID: <3CF3593D.E6C2FE86@lmf.ericsson.se>
Date: Tue, 28 May 2002 13:17:33 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip <sip@ietf.org>
CC: Jonathan Rosemberg <jdrosen@dynamicsoft.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] New version of the SIP over SCTP draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hello,

I have just submitted a new version of the SIP over SCTP draft.

http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sctp-01.txt

I have not changed anything. I have only updated the references (now
they are divided into normative and informative ones).

I am re-submitting this draft because its LC is scheduled for July, and
version 00 expires in May 2002 (i.e., right now).

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@optimus.ietf.org  Tue May 28 09:59:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19068
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 09:59:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA15033
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 10:00:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12967;
	Tue, 28 May 2002 09:32:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12935
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 09:32:17 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18007
	for <sip@ietf.org>; Tue, 28 May 2002 09:31:51 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4SDVaIZ010230;
	Tue, 28 May 2002 06:31:36 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABT02923;
	Tue, 28 May 2002 06:28:36 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA06007; Tue, 28 May 2002 06:31:35 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15603.34487.286237.10847@thomasm-u1.cisco.com>
Date: Tue, 28 May 2002 06:31:35 -0700 (PDT)
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com,
        Miguel Garcia <Miguel.A.Garcia@ericsson.com>
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
In-Reply-To: <3CF32C5C.EBB59A71@dynamicsoft.com>
References: <00b401c20359$0e686310$1d036e3f@TXDWILLIS2>
	<3CF32C5C.EBB59A71@dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


So, I have a really dumb question. Why don't you
limit the number of assertable identities by
cryptographic means? That is, if I can't prove
that I own an identity binding, it gets dumped
on the floor?

	Mike

Jonathan Rosenberg writes:
 > Dean Willis wrote:
 > > 
 > > I'd like to request feedback on the expert review of
 > > draft-garcia-sip-associated URI:
 > > 
 > > Option:
 > > 
 > >    Yeah
 > >    Nay
 > >    Or Needs More Work
 > > 
 > 
 > I think the draft is generally OK, but needs a bit more work. My main
 > area of concern is the applicability statement. It really just repeats
 > the semantics of the header. Really, the scope of applicability is more
 > something like this:
 > 
 > "This specification is applicable in SIP networks where the SIP provider
 > is attempting to restrict the set of identities that a user can claim
 > (in headers like the From field) in requests that it generates. It
 > furthermore assumes that the provider knows the entire set of identities
 > that a user can legitimately claim, and that the user is willing to
 > restrict its claimed identities to that set. In normal SIP usage, the
 > >From field is explicitly an end-user specified field. Effectively, this
 > specification attempts to make it an end-user-specified and provider
 > approved field.
 > 
 > This specification also assumes a closed network model. The restriction
 > of the From field (and other fields) to be among the list of approved
 > values is enforced by a proxy in the domain of the caller. The
 > specification provides no way to indicate or verify to downstream
 > proxies or to the UAS that these fields have been limited in scope. As a
 > result, this specification will only be useful in closed networks where
 > elements know through configuration or administration that the fields
 > have been restricted."
 > 
 > 
 > I also think the security considerations section deserves some more
 > attention. For one thing, I think that the information in this header is
 > very sensitive. It exposes many additional identities for a user, which
 > they might not otherwise want to divulge to everyone. For example, if
 > the URI I register is sip:jdr@example.com, and everyone also has a valid
 > URI which is their full name - sip:jonathan.rosenberg@example.com -
 > eavesdropping the registrations will allow someone to learn my name. The
 > draft alludes to this problem in the second paragraph, but it needs to
 > strengthen the discussion and give specific examples like the one above.
 > 
 > On an unrelated note, I must admit being baffled about why this is
 > useful in a subscribe response. It seems like the associated URI are
 > closely related to registrations, not subscriptions.
 > 
 > 
 > 
 > 
 > 
 > Some minor points:
 > 
 > 1. the syntax does not permit an empty value for the P-Associated-URI.
 > What happens if there are no associated URI? If you simply omit the
 > header altogetrher, how does the UA distinguish the case where the
 > registrar doesn't support the extension, as opposed to the registrar has
 > no associated URIs?
 > 
 > 2. Is there an implicit assumption that the registrar will register the
 > associated URI? I believe this is true in the 3gpp case. A UA probably
 > needs to know whether they have been registered or not. I would not want
 > to put a URI into a Reply-To header unless I knew it was a valid URI for
 > receiving incoming calls....
 > 
 > 3. you write:
 > 
 > > The registrar inserts the P-Associated-URI header into the 200 OK
 > >    response to a REGISTER request. The header is populated with a list of
 > >    URIs that are associated to the registered URI.
 > 
 > probably "address-of-record" is better than "registered URI" in the
 > above.
 > 
 > 4. you write:
 > 
 > > populate the From header value, or any other SIP header value that
 > >    provides information of the identity of the calling party, in a
 > >    subsequent dialog.
 > 
 > s/subsequent dialog/subsequent request
 > 
 > 5. you should probably have an explicit definition of associated URI.
 > 
 > 6. you write:
 > 
 > > 5.3 Procedures at the proxy
 > > 
 > >    This memo does not define any procedures at the proxy.
 > > 
 > 
 > Well, presumably some proxy will enforce the list of associated-URI, and
 > reject requests that have a value in the From field not amongst the
 > allowed set? Is there a new response code for that?
 > 
 > 
 > Thanks,
 > Jonathan R.
 > 
 > 
 > 
 > -- 
 > Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
 > Chief Scientist                         First Floor
 > dynamicsoft                             East Hanover, NJ 07936
 > jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
 > http://www.jdrosen.net                  PH:  (973) 952-5000
 > http://www.dynamicsoft.com
 > 
 > _______________________________________________
 > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
 > This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May 28 10:14:40 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19648
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 10:14:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA16639
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 10:15:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14203;
	Tue, 28 May 2002 09:46:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA14174
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 09:46:45 -0400 (EDT)
Received: from repulse.cnchost.com (repulse.concentric.net [207.155.248.4])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18573
	for <sip@ietf.org>; Tue, 28 May 2002 09:46:20 -0400 (EDT)
Received: from deewana (pool-138-88-38-201.res.east.verizon.net [138.88.38.201])
	by repulse.cnchost.com
	id JAA28996; Tue, 28 May 2002 09:46:40 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.14]
Message-ID: <001b01c2064f$f2df78f0$0100000a@nextone.com>
From: "Medhavi Bhatia" <mbhatia@nextone.com>
To: <sip@ietf.org>
Date: Tue, 28 May 2002 09:59:55 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] media source port in SDP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

I remember there was a discussion some while back about specifying the
source port for the media in the SDP. Is that standardized yet ? I am still
seeing some vendors using the RFC 2327 format, and assuming that the
source port for media will be the same as the receive port specified in the
SDP.
Is that correct or standardized somewhere ?

Medhavi.


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



From daemon@optimus.ietf.org  Tue May 28 10:38:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20428
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 10:38:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA18657
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 10:39:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16346;
	Tue, 28 May 2002 10:09:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16313
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 10:09:52 -0400 (EDT)
Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19403
	for <sip@ietf.org>; Tue, 28 May 2002 10:09:26 -0400 (EDT)
Received: from ih2mail.ih.lucent.com (h135-1-241-39.lucent.com [135.1.241.39])
	by auemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4SE9Id13012;
	Tue, 28 May 2002 10:09:18 -0400 (EDT)
Received: from lucent.com by ih2mail.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id JAA25971; Tue, 28 May 2002 09:09:17 -0500 (CDT)
Message-ID: <3CF38F73.7010107@lucent.com>
Date: Tue, 28 May 2002 09:08:51 -0500
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Lucent Technologies, Inc./Bell Laboratories
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Prabhas Sinha <prsinha@unity.ncsu.edu>
CC: Jeff Keyser <JKeyser@telocity.com>,
        "SIP Mailing List (E-mail)"
 <sip@ietf.org>
Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09
References: <000401c205d4$200e7820$1200a8c0@dsl6419231101.telocity.com> <389c01c205e3$273eb010$743c0198@ecew2k.ncsu.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Prabhas Sinha wrote:
> Thanks for bringing this up Jeff. I too had asked this question some time
> back to Vijay Gurbani.
> Even I am waiting to get some clarifications on it if I didnt understand 
> the model.

The protocol state machine for the INVITE transaction is accurate as
it stands (a fair amount of derivative work has been done based on it,
so it's soundness is not an issue).

To understand why the state machine is as shown, you need to recognize
that the ACK to a 200 OK (INVITE) consists of a separate transaction
entirely.  It may be routed separatley from the INVITE that triggered
it.  ACKs for non-2xx responses to INVITE are considered part of the
same transaction, and in fact, are propogated on a hop-by-hop basis.

Hence, when the client state machine gets a 200 OK to an INVITE, it
enters the Terminated state (since the ACK will be a new transaction).
When the client state machine gets a non-2xx, it will generate the
ACK and then enter the Terminated state.

Hope that helps.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216


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



From daemon@optimus.ietf.org  Tue May 28 11:52:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22714
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 11:52:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA23330
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 11:52:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21169;
	Tue, 28 May 2002 11:19:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21144
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 11:19:32 -0400 (EDT)
Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21654
	for <sip@ietf.org>; Tue, 28 May 2002 11:19:06 -0400 (EDT)
Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227])
	by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA28627;
	Tue, 28 May 2002 17:19:14 +0200 (MET DST)
Received: from mchh169e.mch4.siemens.de ([139.21.130.176])
	by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA06275;
	Tue, 28 May 2002 17:19:28 +0200 (MET DST)
Received: by mchh169e.mch4.siemens.de with Internet Mail Service (5.5.2653.19)
	id <LYC3VL0T>; Tue, 28 May 2002 17:19:30 +0200
Message-ID: <5B4D0C5BA65ECA46969C1419122317E6E74DE6@mchh161e>
From: Tan Ya-Ching  ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
To: "'bcampbell@dynamicsoft.com'" <bcampbell@dynamicsoft.com>
Cc: sip@ietf.org
Subject: [SIP] Provisional response for MESSAGE
Date: Tue, 28 May 2002 17:19:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

The last paragraph of draft-ietf-sip-message-04 section 9 states that :

"It has been suggested that provisional responses should not be used
for pager-model MESSAGE requests.  However, this is not possible, as
many proxy servers will not be aware of the MESSAGE method, and will
treat MESSAGE requests using the standard non-invite transaction.
Additionally, prohibiting provisional responses may in some cases
increase the number of retries, and actually make congestion problems
worse.  Therefore MESSAGE requests SHOULD receive the same
provisional response treatment as any other non-INVITE method, as
described in the SIP specification."

But RFC 3261 (8.2.6.1 for UAS, 16.2 for stateful proxy, 16.11 stateless
proxy) states that provisional response SHOULD NOT be issued for a
non-INVITE request. So this is effectively 'prohibiting provisional
responses' and 'may in some cases increase the number of retries'.


Regards,
Ya-Ching




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



From daemon@optimus.ietf.org  Tue May 28 12:16:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23621
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 12:16:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA26141
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:16:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23309;
	Tue, 28 May 2002 11:51:49 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23232
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 11:51:45 -0400 (EDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22673;
	Tue, 28 May 2002 11:51:20 -0400 (EDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 08:51:10 -0700
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 08:51:10 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 08:51:10 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 28 May 2002 08:51:10 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0);
	 Tue, 28 May 2002 08:51:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 08:51:09 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E538@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
thread-index: AcIByNPUE2XbCWMZTheCqot6fIRBLgElfF6g
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: <iesg@ietf.org>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 28 May 2002 15:51:09.0875 (UTC) FILETIME=[7C699830:01C2065F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA23235
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

I have a major issue with this spec, namely that the security problems
are not addressed. The security section correctly lists one of the main
security threats, the spoofing of a DHCP server:

   The security considerations in RFC XXXX [1], RFC 3261 [2] and RFC
   3263 [3] apply. If an adversary manages to modify the response from a
   DHCP server or insert its own response, a SIP user agent could be led
   to contact a rogue SIP server, possibly one that then intercepts call
   requests or denies service. A modified DHCP answer could also omit
   host names that translated to TLS-based SIP servers, thus
   facilitating intercept.

This is a very real attack, especially in the deployment phase of IPv6,
when there may not even be an actual DHCPv6 server on the local network.
Think for example of an 802.11 hotpoint, in which any enterprising
attacker could publish his very own DHCPv6 server. Yet, the security
work seems to stop here. There is no attempt at mitigating the attack.
IMHO, we should not publish a spec that open the door for a grave attack
and offers no mitigation.

-- Christian Huitema

> -----Original Message-----
> From: The IESG [mailto:iesg-secretary@ietf.org]
> Sent: Wednesday, May 22, 2002 12:21 PM
> Cc: sip@ietf.org
> Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed
> Standard
> 
> 
> The IESG has received a request from the Session Initiation Protocol
> Working Group to consider DHCPv6 Options for SIP Servers
> <draft-ietf-sip-dhcpv6-00.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 any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002.
> 
> Files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt
> 
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May 28 12:48:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24405
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 12:48:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA28371
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:48:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26614;
	Tue, 28 May 2002 12:22:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26537
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 12:22:47 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23827;
	Tue, 28 May 2002 12:22:21 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA06444;
	Tue, 28 May 2002 12:22:40 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SGMd2i012740
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 28 May 2002 12:22:39 -0400 (EDT)
Message-ID: <3CF3AEB2.5020702@cs.columbia.edu>
Date: Tue, 28 May 2002 12:22:10 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: iesg@ietf.org, sip@ietf.org
Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
References: <F66A04C29AD9034A8205949AD0C9010401C0E538@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Christian,

thanks for your comment. I'm slightly confused, however, why this 
particular problem is any different for SIP servers than for any other, 
non-SIP server identified by a DHCPv6 server. Also, Section 21 of 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-25.txt 
addresses this particular issue. Could you clarify your comments in 
these two aspects?

Henning

Christian Huitema wrote:
> I have a major issue with this spec, namely that the security problems
> are not addressed. The security section correctly lists one of the main
> security threats, the spoofing of a DHCP server:
> 
>    The security considerations in RFC XXXX [1], RFC 3261 [2] and RFC
>    3263 [3] apply. If an adversary manages to modify the response from a
>    DHCP server or insert its own response, a SIP user agent could be led
>    to contact a rogue SIP server, possibly one that then intercepts call
>    requests or denies service. A modified DHCP answer could also omit
>    host names that translated to TLS-based SIP servers, thus
>    facilitating intercept.
> 
> This is a very real attack, especially in the deployment phase of IPv6,
> when there may not even be an actual DHCPv6 server on the local network.
> Think for example of an 802.11 hotpoint, in which any enterprising
> attacker could publish his very own DHCPv6 server. Yet, the security
> work seems to stop here. There is no attempt at mitigating the attack.
> IMHO, we should not publish a spec that open the door for a grave attack
> and offers no mitigation.
> 
> -- Christian Huitema
> 
> 
>>-----Original Message-----
>>From: The IESG [mailto:iesg-secretary@ietf.org]
>>Sent: Wednesday, May 22, 2002 12:21 PM
>>Cc: sip@ietf.org
>>Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed
>>Standard
>>
>>
>>The IESG has received a request from the Session Initiation Protocol
>>Working Group to consider DHCPv6 Options for SIP Servers
>><draft-ietf-sip-dhcpv6-00.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 any comments to the
>>iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002.
>>
>>Files can be obtained via
>>http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt
>>
>>
>>
>>
>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May 28 12:50:17 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24535
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 12:50:17 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA28525
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:50:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26734;
	Tue, 28 May 2002 12:24:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26700
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 12:24:06 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23890
	for <sip@ietf.org>; Tue, 28 May 2002 12:23:41 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SGOxYH025062;
	Tue, 28 May 2002 12:24:59 -0400 (EDT)
Message-ID: <3CF3AEF9.EF57314C@dynamicsoft.com>
Date: Tue, 28 May 2002 12:23:21 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com,
        Miguel Garcia <Miguel.A.Garcia@ericsson.com>
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <15603.34487.286237.10847@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Michael Thomas wrote:
> 
> So, I have a really dumb question. Why don't you
> limit the number of assertable identities by
> cryptographic means? That is, if I can't prove
> that I own an identity binding, it gets dumped
> on the floor?

Sure; I think the issue (Miguel can correct me if I'm wrong), is that
the UA needs to be configured with the set of identities it can claim in
the first place. The same credentials would allow the user to assert any
one of those, but the phone needs to know which it should present to the
user to use.

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Tue May 28 12:51:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24573
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 12:51:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA28647
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 12:51:40 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27474;
	Tue, 28 May 2002 12:31:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27450
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 12:31:26 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24093
	for <sip@ietf.org>; Tue, 28 May 2002 12:31:01 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SGWJYH025117;
	Tue, 28 May 2002 12:32:19 -0400 (EDT)
Message-ID: <3CF3B0B1.F176F2F4@dynamicsoft.com>
Date: Tue, 28 May 2002 12:30:41 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <3CF3596B.13D72E7@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



"Miguel A. Garcia" wrote:
> 

> > On an unrelated note, I must admit being baffled about why this is
> > useful in a subscribe response. It seems like the associated URI are
> > closely related to registrations, not subscriptions.
> 
> And in fact, the only usage in 3GPP is in registrations. But I got
> some comments that this may be useful in subscriptions as well. If
> nobody
> shouts, I will remove the usage of the header in subscriptions and
> restrict
> the scope to REGISTER only.

Yes, please. I think we should strive to limit scope for P-headers, not
the other way around. This is especially true when the motivating need
is not even clear.


> > 1. the syntax does not permit an empty value for the P-Associated-URI.
> > What happens if there are no associated URI? If you simply omit the
> > header altogetrher, how does the UA distinguish the case where the
> > registrar doesn't support the extension, as opposed to the registrar
> has
> > no associated URIs?
> 
> Do we need to make a distinction between both cases? Either case, the
> user knows that no other identities are associated by the registrar,
> and therefore, explicit actions (e.g., REGISTER) has to be taken by
> the UAC.

I thought you indicated below that this extension did not imply the
registration of the associated identities...

That aside, it does make a difference. The UA needs to know whether it
can put any identity it likes in the From field (since the network is
not trying to impose restrictions on the set), or whether it can't put
any identity except the one it registered (since the network is imposing
restrictions, and there is just one valid identity). 


> > 2. Is there an implicit assumption that the registrar will register
> the
> > associated URI? I believe this is true in the 3gpp case. A UA probably
> > needs to know whether they have been registered or not. I would not
> want
> > to put a URI into a Reply-To header unless I knew it was a valid URI
> for
> > receiving incoming calls....
> 
> No, this is not the case. The "reg" event will provide such information.
> But the semantics of this header is just to provide a set of IDs that
> the
> user has associated to the address-of-record. They may or may not be
> registered,
> the user will know this information by other means (subscription to the
> registration event package). The user knows that he can initiate
> registration
> of any of the returned IDs, or it can populate the From with any of
> those
> IDs as well. That's it.

Presumably the UA will need to make sure that they are registered; you
should probably note in the draft that there is no assumption that the
associated URI are registered, and that if the UA wants that, it should
check and perform the registrations if needed.

> > > 5.3 Procedures at the proxy
> > >
> > >    This memo does not define any procedures at the proxy.
> > >
> >
> > Well, presumably some proxy will enforce the list of associated-URI,
> and
> > reject requests that have a value in the From field not amongst the
> > allowed set? Is there a new response code for that?
> 
> Yes, the proxy will send a 403 Forbidden. However, I don't think this is
> 
> part of the scope of this I-D. I understand that the title "Procedures
> at
> the proxy" are procedures related to the extension (the header in this
> case).
> The idea in this I-D is to convey to the UA the list of URIs that he can
> use
> in subsequent requests, not how to police them. Therefore, there are not
> procedures at the proxy related to the P-Associated-URI header.

Well, its all intertwined. The associated-URI list is the only way a UA
has to retry if it should get this error, since it conveys the allowed
URI in the first place. Actually, 403 is really NOT the right response.
If it gets this, how does the UA recover? It needs to know that the
problem was a disallowed From value, and it needs to know which ones are
OK. I would argue that the way to deal with this is a new response code
that would contain in it the Associated-URI header indicating which ones
are allowed.

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

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



From daemon@optimus.ietf.org  Tue May 28 13:04:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25022
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 13:04:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA29716
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:05:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28056;
	Tue, 28 May 2002 12:44:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28030
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 12:44:34 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24283
	for <sip@ietf.org>; Tue, 28 May 2002 12:44:09 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SGj2YH025130;
	Tue, 28 May 2002 12:45:02 -0400 (EDT)
Message-ID: <3CF3B3AC.48C27A59@dynamicsoft.com>
Date: Tue, 28 May 2002 12:43:24 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com,
        hgs@cs.columbia.edu
Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6
References: <004801c201b8$8b4f1060$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

One comment.

One of the things we need to be striving for is to move everything
consistently towards the usage of loose routing for sending requests
through intermediate hops. This has countless benefits, primarily
derived from the ability to associate parameters and other information
with the loose route URI. A local outbound proxy is most definitely a
hop that can be specified with a loose route. So, while bis does allow a
UAC to simply send requests to a configured IP/FQDN rather than use
loose routing, it recommends loose routing. 

So, my question is this: why don't we specify that the DHCP option
provides you a URI that is used as a loose route, and not a domain
name/IP address? Wouldn't that handle v6,v4 domain names and everything
else?

Also, I suspect that in many cases, local outbound proxies will be doing
compression. How does the client know whether it can send compressed sip
messages to its proxy? Well, we have a URI parameter for this purpose:

http://search.ietf.org/internet-drafts/draft-camarillo-sip-sigcomp-00.txt

Thus, if the client learns about the local outbound proxy through a URI,
it will be able to learn whether it supports compression. If only the
address/domain name are provided, separate means are needed to learn
about support for compression.

Thanks,
Jonathan R.

Dean Willis wrote:
> 
> We started working group last call of the sip-dhcpv6 draft on May 2.
> There has been no negative veedback that I'm aware of, so let's call
> WGLC complete and request IETF Last Call.
> 
> http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt
> 
> --
> 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

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

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



From daemon@optimus.ietf.org  Tue May 28 13:15:13 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25435
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 13:15:11 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA00487
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:15:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28613;
	Tue, 28 May 2002 12:50:47 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA28540
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 12:50:43 -0400 (EDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24539;
	Tue, 28 May 2002 12:50:17 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 09:50:11 -0700
Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 09:50:11 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 09:50:10 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 28 May 2002 09:50:10 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0);
	 Tue, 28 May 2002 09:50:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 09:50:09 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E539@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
thread-index: AcIGY+cZgCz9UYC8TO+NqTOeZsi1HwAAayzA
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: <iesg@ietf.org>, <sip@ietf.org>
X-OriginalArrivalTime: 28 May 2002 16:50:10.0190 (UTC) FILETIME=[BA9ACAE0:01C20667]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA28542
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

There are multiple issues with your reference to the DHCPv6 draft.
First, let me observe that the DHCPv6 draft proposes two security
solutions, the use of "delayed authentication", which relies on a
pre-shared key, and the use of IPSEC, for which key negotiation and key
validation is not specified. At a minimum, the SIP option draft should
explain how these mechanisms can be used to mitigate the SIP-specific
security risks. We should also explain in which contexts these security
mechanisms can be used. For example, the DHCPv6 draft states that:

   The "delayed authentication" protocol does not attempt to address
   situations where a client may roam from one administrative domain
   to another, i.e.  interdomain roaming. This protocol is focused on
   solving the intradomain problem where the out-of-band exchange of a
   shared key is feasible.

Shall we conclude that the SIP option should not be used in roaming
scenarios? If that is the case, then we have a serious application
domain restriction, which should be very clearly stated in the SIP
option draft. If you actually want to address a roaming scenario, then
you have to describe how you are going to use IPSEC between the server
and the client, and how you are going to validate the IPSEC keys.

The DHCPv6 document itself is still a draft. Since you need a normative
reference, the publication of the SIP option has to be gated by the
publication of DHCPv6 itself.

Finally, there are security issues with the very concept of an outgoing
proxy, which is essentially a "man-in-the-middle" by design.  I would
expect SIP agents to perform some level of validation before they decide
to use the outgoing proxy proposed by the local network. In most roaming
scenarios, the SIP agent will probably elect to simply maintain a secure
connection with its "home server", and ignore the local proxy -- just
like most mail agent simply get their mail using an IMAP or POP3
connection to their mail server, instead of forwarding the mail to a
local server.

-- Christian Huitema

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, May 28, 2002 9:22 AM
> To: Christian Huitema
> Cc: iesg@ietf.org; sip@ietf.org
> Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to
Proposed
> Standard
> 
> Christian,
> 
> thanks for your comment. I'm slightly confused, however, why this
> particular problem is any different for SIP servers than for any
other,
> non-SIP server identified by a DHCPv6 server. Also, Section 21 of
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-25.txt
> addresses this particular issue. Could you clarify your comments in
> these two aspects?
> 
> Henning
> 
> Christian Huitema wrote:
> > I have a major issue with this spec, namely that the security
problems
> > are not addressed. The security section correctly lists one of the
main
> > security threats, the spoofing of a DHCP server:
> >
> >    The security considerations in RFC XXXX [1], RFC 3261 [2] and RFC
> >    3263 [3] apply. If an adversary manages to modify the response
from a
> >    DHCP server or insert its own response, a SIP user agent could be
led
> >    to contact a rogue SIP server, possibly one that then intercepts
call
> >    requests or denies service. A modified DHCP answer could also
omit
> >    host names that translated to TLS-based SIP servers, thus
> >    facilitating intercept.
> >
> > This is a very real attack, especially in the deployment phase of
IPv6,
> > when there may not even be an actual DHCPv6 server on the local
network.
> > Think for example of an 802.11 hotpoint, in which any enterprising
> > attacker could publish his very own DHCPv6 server. Yet, the security
> > work seems to stop here. There is no attempt at mitigating the
attack.
> > IMHO, we should not publish a spec that open the door for a grave
attack
> > and offers no mitigation.
> >
> > -- Christian Huitema
> >
> >
> >>-----Original Message-----
> >>From: The IESG [mailto:iesg-secretary@ietf.org]
> >>Sent: Wednesday, May 22, 2002 12:21 PM
> >>Cc: sip@ietf.org
> >>Subject: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed
> >>Standard
> >>
> >>
> >>The IESG has received a request from the Session Initiation Protocol
> >>Working Group to consider DHCPv6 Options for SIP Servers
> >><draft-ietf-sip-dhcpv6-00.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 any comments to the
> >>iesg@ietf.org or ietf@ietf.org mailing lists by June 5, 2002.
> >>
> >>Files can be obtained via
> >>http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt
> >>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May 28 13:38:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26167
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 13:38:54 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA02161
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:39:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00438;
	Tue, 28 May 2002 13:13:06 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA00413
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 13:13:04 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25341
	for <sip@ietf.org>; Tue, 28 May 2002 13:12:38 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA10649;
	Tue, 28 May 2002 13:12:41 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SHCe2i015117
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 28 May 2002 13:12:40 -0400 (EDT)
Message-ID: <3CF3BA6A.7090700@cs.columbia.edu>
Date: Tue, 28 May 2002 13:12:10 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6
References: <004801c201b8$8b4f1060$1d036e3f@TXDWILLIS2> <3CF3B3AC.48C27A59@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I agree that this would be useful, albeit a bit unusual compared to 
other DHCP options. There are a few issues that would need to be resolved:

- Would this apply to v6 only? I don't know that the state of the v4 
draft is in the IESG pipeline and what other "customers" there are. This 
would be the first DHCP option containing a URI, so this may cause some 
broader issues.

- It would be possible to add this mode as a third mechanism on top of 
the existing two (either as the byte identifier in v4 or as top-level 
items in v6) in both v4 and v6. That would seem to be the least likely 
to cause hick-ups.

- As the only mode, URIs would not be amenable to DNS host name 
compression, so this is not quite equivalent. I suspect that that is a 
minor issue.

Jonathan Rosenberg wrote:
> One comment.
> 
> One of the things we need to be striving for is to move everything
> consistently towards the usage of loose routing for sending requests
> through intermediate hops. This has countless benefits, primarily
> derived from the ability to associate parameters and other information
> with the loose route URI. A local outbound proxy is most definitely a
> hop that can be specified with a loose route. So, while bis does allow a
> UAC to simply send requests to a configured IP/FQDN rather than use
> loose routing, it recommends loose routing. 
> 
> So, my question is this: why don't we specify that the DHCP option
> provides you a URI that is used as a loose route, and not a domain
> name/IP address? Wouldn't that handle v6,v4 domain names and everything
> else?
> 
> Also, I suspect that in many cases, local outbound proxies will be doing
> compression. How does the client know whether it can send compressed sip
> messages to its proxy? Well, we have a URI parameter for this purpose:
> 
> http://search.ietf.org/internet-drafts/draft-camarillo-sip-sigcomp-00.txt
> 
> Thus, if the client learns about the local outbound proxy through a URI,
> it will be able to learn whether it supports compression. If only the
> address/domain name are provided, separate means are needed to learn
> about support for compression.
> 
> Thanks,
> Jonathan R.
> 
> Dean Willis wrote:
> 
>>We started working group last call of the sip-dhcpv6 draft on May 2.
>>There has been no negative veedback that I'm aware of, so let's call
>>WGLC complete and request IETF Last Call.
>>
>>http://search.ietf.org/internet-drafts/draft-ietf-sip-dhcpv6-00.txt
>>
>>--
>>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 daemon@optimus.ietf.org  Tue May 28 13:55:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26590
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 13:55:59 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA03271
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 13:56:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01779;
	Tue, 28 May 2002 13:31:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01709
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 13:31:44 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26014;
	Tue, 28 May 2002 13:31:18 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA12336;
	Tue, 28 May 2002 13:31:41 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SHVe2i015906
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 28 May 2002 13:31:40 -0400 (EDT)
Message-ID: <3CF3BEDE.4060703@cs.columbia.edu>
Date: Tue, 28 May 2002 13:31:10 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: iesg@ietf.org, sip@ietf.org
Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
References: <F66A04C29AD9034A8205949AD0C9010401C0E539@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

>    The "delayed authentication" protocol does not attempt to address
>    situations where a client may roam from one administrative domain
>    to another, i.e.  interdomain roaming. This protocol is focused on
>    solving the intradomain problem where the out-of-band exchange of a
>    shared key is feasible.
> 
> Shall we conclude that the SIP option should not be used in roaming
> scenarios? If that is the case, then we have a serious application
> domain restriction, which should be very clearly stated in the SIP
> option draft. If you actually want to address a roaming scenario, then
> you have to describe how you are going to use IPSEC between the server
> and the client, and how you are going to validate the IPSEC keys.

It would be helpful to have the 3G folks chime in here. Realistically, 
we aren't going to be developing new IPsec key distribution protocols 
for this application, but 3G may already have to deliver a shared secret 
in a remote (away from home) environment.

As a side note, I find this restriction a rather serious one beyond SIP: 
After all, DHCP is most useful when I'm away from my home network. In my 
home network, I can easily configure things statically.


> 
> The DHCPv6 document itself is still a draft. Since you need a normative
> reference, the publication of the SIP option has to be gated by the
> publication of DHCPv6 itself.

That is clearly the case. I'm sure the IESG will ensure that :-)

> 
> Finally, there are security issues with the very concept of an outgoing
> proxy, which is essentially a "man-in-the-middle" by design.  I would
> expect SIP agents to perform some level of validation before they decide
> to use the outgoing proxy proposed by the local network. In most roaming
> scenarios, the SIP agent will probably elect to simply maintain a secure
> connection with its "home server", and ignore the local proxy -- just
> like most mail agent simply get their mail using an IMAP or POP3
> connection to their mail server, instead of forwarding the mail to a
> local server.

There are lots of proxies that the caller has no control over (among 
others, any proxies in the callee's domain), so this is hardly new.

They may not have a choice if the local outbound proxy controls the 
firewall. Thus, having a secure connection to a home proxy might get the 
SIP packets through, but will make for a rather silent phone conversation.



> 
> -- Christian Huitema


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



From daemon@optimus.ietf.org  Tue May 28 14:20:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27207
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 14:20:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA04770
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 14:20:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04069;
	Tue, 28 May 2002 14:02:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA04043
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 14:02:19 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26711
	for <sip@ietf.org>; Tue, 28 May 2002 14:01:53 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A62893200306; Tue, 28 May 2002 14:02:16 -0400
Message-ID: <002001c20671$db2b14e0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>,
        "Tan Ya-Ching ICM N PG U ID A 1" <Ya-Ching.Tan@icn.siemens.de>
Cc: <sip@ietf.org>
References: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e> <3CF1FC20.3CFDAEE6@ericsson.com>
Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01
Date: Tue, 28 May 2002 14:02:39 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

A couple follow-ups and one new comment below

----- Original Message -----
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
<snip>
> Tan Ya-Ching ICM N PG U ID A 1 wrote:
><snip>
>
> > | >   I do not see how these statements meet the requirement of
> > | [3], which
> > | > states :
> > | >
> > | >   "An applicability statement in the Informational RFC MUST
> > | >    clearly document the useful scope of the proposal, and explain
> > | >    its limitations and why it is not suitable for the general use
> > | >    of SIP in the Internet."
> > |
> > | <miguel>
> > | My effort was to scope as much as possible this header. It is suitable
> > | for the general use of SIP in the Internet, so I have nothing else to
> > | say.
> > | </miguel>
> >
> > If it is suitable for the general use, why a P-header ?
>
> <miguel>
> Because so far nobody else has the requirement as we expressed.
> That's why we are going for a P- header. But the extension itself
> is not restricted to 3GPP. It is generally applicable to the Internet.
> </miguel>

Does the fact that one would want to use P-Called-Party-ID when they cannot
(or will not) rely on the To field, need be included in the applicability
statement?

><snip>
> > | >   o The term "standalone method" is not defined in SIP RFC.
> > |
> > | <miguel>
> > | I'll fix it somehow, but I think that the term standalone,
> > | although not define in RFC 3261, is understandable by the
> > | reader familiar with SIP.
> > | </miguel>
> >
> > RFC 3261 even defines terms such as "Message", "Parallel Search". One
simply
> > can't start using a new term like "standalone request" or "standalone
> > transaction request" and assume that it is 'understandable by the reader
> > familiar with SIP'.
> >
>
> <miguel>Yes, I understand your comment. I will do my best to make it
> clear what it means in the next version.
> </miguel>

I think what you are trying to say is that the P-Called-Party-ID can be
inserted in any request that initiates a dialog, or any request that is
completely outside of a dialog. These should be the only requests that would
have been issued with an AOR type Request-URI that a proxy would replace.
All other requests (those within an existing dialog) would have a
Request-URI equal to a URI that the UA learned from a Contact header in the
request/response that created the dialog. Is this correct?

New issue:

In the header field table in Section 5, shouldn't the header be optional for
a SUBSCRIBE and not allowed for a NOTIFY? SUBSCRIBE initiates a dialog, and
NOTIFY should use the value from the Contact of the SUBSCRIBE for the R-URI
(thus R-URI would not be changed by a proxy).

cheers,
(-:bob



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



From daemon@optimus.ietf.org  Tue May 28 14:50:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27835
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 14:50:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA06661
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 14:51:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05810;
	Tue, 28 May 2002 14:32:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05739
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 14:32:03 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27485
	for <sip@ietf.org>; Tue, 28 May 2002 14:31:39 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SIUkd11494;
	Tue, 28 May 2002 13:30:46 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Juha Heinanen'" <jh@lohi.eng.song.fi>,
        "'Cullen Jennings'" <fluffy@cisco.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00
Date: Tue, 28 May 2002 13:30:06 -0500
Message-ID: <00ac01c20675$b0e01150$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <15603.12344.116679.526241@lohi.eng.song.fi>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Juha wrote:
> once again:
> 
> the term "hint" is not a good one.  if user adds the a-i, 
> then the network MUST respect it or reject the request.  the 
> network MUST not override the a-i and pick one of the 
> identities on its own.  for example, the user may have 
> misspelled the its uri in the a-i.
> 
> also, the text should say that in case from is anonymous the 
> user MUST insert the a-i header if it has multiple 
> identities, because otherwise the network cannot know which 
> identity the user wants to use.
> 
> finally, for backwards compatibility, if from is not 
> anonymous and the user has multiple identities, then from uri 
> can serve as the purpose of a-i.

Oh my! I think Juha is absolutely correct, in the nost common case. Of
course, there may be other cases.

Commonly, the UA asserts an identity. If it has credentials to do so
(say, a cert issued by a trusted CA) it MAY use those credentials to
provide support for its assertion.

An intermediate service node (authentication or identification server)
MAY also support the assertion by applying its own credentials.

In the common case, the identification server would be expected to
support the assertion made by the UA if the UA made any assertion of
identity. If the UA doesn't assert identity with a-i, then one might
consider the "from" field as a lower-strength assertion of identity, and
the identification server could cryptographically support that identity.
One could also establish the identity to be asserted based on the
identity used in authentication (with digest, for example) or as a
matter of policy (the user didn't say, so they get their "default"
identity asserted).

Of course, there may be special agreements between the user and the
identification server which fall outside this common usage.

Consider, for example, the "anonymization server". Such a server might
strip away all other user identity information, substituting  a "stage
name" (say, "sip:userx@anonymizer.com"), which would then be
cryptographically supported by the server. Such a construction would not
be depdendent on any kind of "hinting" mechanism. It would have the
advantage of traceability and nonrepudiability back to the anonymizer
service, which could then (if needed) provide reachability back to the
actual user. This application, while not the general case, does
represent a mode in which the requirements put forth by Juha in the
above text do not actually apply.

So I think it important to differentiate the common usage from the
possible usage. This suggests softening some of the MUSTs suggested by
Juha into SHOULDs, accompanied by appropriate discussion of the possible
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 daemon@optimus.ietf.org  Tue May 28 15:28:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28417
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:28:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA09240
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:29:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07955;
	Tue, 28 May 2002 15:09:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA07921
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:09:01 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28174
	for <sip@ietf.org>; Tue, 28 May 2002 15:08:36 -0400 (EDT)
Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SJ8THs018750
	for <sip@ietf.org>; Tue, 28 May 2002 12:08:29 -0700 (PDT)
Received: from cisco.com (rtp-vpn2-439.cisco.com [10.82.241.183]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA03218 for <sip@ietf.org>; Tue, 28 May 2002 12:08:21 -0700 (PDT)
Message-ID: <3CF3D5A4.18AA6208@cisco.com>
Date: Tue, 28 May 2002 15:08:20 -0400
From: Flemming Andreasen <fandreas@cisco.com>
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "'sip@ietf.org'" <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Updated call-auth draft with one change
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Greetings

As a result of IESG review, we have updated the call-auth draft which
you can now get from


http://search.ietf.org/internet-drafts/draft-ietf-sip-call-auth-06.txt

While incorporating the IESG comments, we discovered, that with the
grammar change from the -04 to -05, it no longer made sense to include
the Length field from the RFC 2750 Policy Element. Consequently, the
document now says, that the Length field is excluded. I thought you
might like to know that.

Regards

        Flemming






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



From daemon@optimus.ietf.org  Tue May 28 15:41:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28886
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:41:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10676
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:41:59 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09014;
	Tue, 28 May 2002 15:25:23 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08944
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:25:12 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28341
	for <sip@ietf.org>; Tue, 28 May 2002 15:24:47 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNud11774;
	Tue, 28 May 2002 14:23:56 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>, <rohan@cisco.com>, <brian.rosen@marconi.com>,
        <jo@ipdialog.com>
Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
Date: Tue, 28 May 2002 14:23:13 -0500
Message-ID: <00b001c2067d$1e30aba0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3CF3596B.13D72E7@ericsson.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Miguel said:
> Jonathan said:
> > Well, presumably some proxy will enforce the list of 
> associated-URI, 
> > and reject requests that have a value in the From field not amongst 
> > the allowed set? Is there a new response code for that?
> 
> Yes, the proxy will send a 403 Forbidden. However, I don't 
> think this is 
> part of the scope of this I-D. I understand that the title 
> "Procedures at the proxy" are procedures related to the 
> extension (the header in this case). The idea in this I-D is 
> to convey to the UA the list of URIs that he can use 
> in subsequent requests, not how to police them. Therefore, 
> there are not procedures at the proxy related to the 
> P-Associated-URI header.

Actually, this policy enforcement is being made by the
3GPP-specific-back-to-back-user-agent-that-sometimes-acts-kindof-like-a-
proxy called the P-CSCF. Documenting the behavior of this rather
specalized node is probably far outside the scope of an IETF effort.
Proxies, in general, are not expected to restrict the range of identity
expression allowed to a user based on some sort of P-header. In fact,
one might argue that proxies in general are PROHIBITED from doing this
sort of 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 daemon@optimus.ietf.org  Tue May 28 15:42:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28938
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:42:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10761
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:43:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09134;
	Tue, 28 May 2002 15:27:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09095
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:27:22 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28362
	for <sip@ietf.org>; Tue, 28 May 2002 15:26:58 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJRmYH025293;
	Tue, 28 May 2002 15:27:48 -0400 (EDT)
Message-ID: <3CF3D9D4.BFE306AC@dynamicsoft.com>
Date: Tue, 28 May 2002 15:26:12 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6
References: <3CF3BA6A.7090700@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:
> 
> I agree that this would be useful, albeit a bit unusual compared to
> other DHCP options. There are a few issues that would need to be
> resolved:
> 
> - Would this apply to v6 only? I don't know that the state of the v4
> draft is in the IESG pipeline and what other "customers" there are. This
> 
> would be the first DHCP option containing a URI, so this may cause some
> broader issues.

Understood. Its definitely not v6 specific. Maybe we need to define it
separately because its too late or controversial. My main point is that
technically, I think it is far superior to using IP addresses or domain
names.

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

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



From daemon@optimus.ietf.org  Tue May 28 15:43:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28955
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:43:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10776
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:43:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08743;
	Tue, 28 May 2002 15:24:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08666
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:24:28 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28308;
	Tue, 28 May 2002 15:24:04 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNtd11771;
	Tue, 28 May 2002 14:23:56 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>, <iesg@ietf.org>
Cc: <sip@ietf.org>
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 14:23:13 -0500
Message-ID: <00af01c2067d$1da42310$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010401C0E538@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Christian wrote:
> I have a major issue with this spec, namely that the security 
> problems are not addressed. The security section correctly 
> lists one of the main security threats, the spoofing of a DHCP server:

Yes, this is a real issue. 

But isn't this sort of a general DHCP problem rather than one specific
to the usage of SIP? 

Do we need to bascially stop using DHCP while working on it, and if so
is this (SIP working group) the right forum to try and tackle that?

--
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 daemon@optimus.ietf.org  Tue May 28 15:44:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29001
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:44:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10823
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:44:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08976;
	Tue, 28 May 2002 15:25:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08910
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:25:08 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28339
	for <sip@ietf.org>; Tue, 28 May 2002 15:24:43 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNvd11777;
	Tue, 28 May 2002 14:23:57 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Michael Thomas'" <mat@cisco.com>
Cc: <sip@ietf.org>, <rohan@cisco.com>, <brian.rosen@marconi.com>,
        <jo@ipdialog.com>, "'Miguel Garcia'" <Miguel.A.Garcia@ericsson.com>
Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
Date: Tue, 28 May 2002 14:23:13 -0500
Message-ID: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3CF3AEF9.EF57314C@dynamicsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> Michael Thomas wrote:
> > 
> > So, I have a really dumb question. Why don't you
> > limit the number of assertable identities by
> > cryptographic means? That is, if I can't prove
> > that I own an identity binding, it gets dumped
> > on the floor?
> 
> Sure; I think the issue (Miguel can correct me if I'm wrong), 
> is that the UA needs to be configured with the set of 
> identities it can claim in the first place. The same 
> credentials would allow the user to assert any one of those, 
> but the phone needs to know which it should present to the 
> user to use.

It goes a little further than this. We're also informing the UA of a
number of extisting "aliases". The UA can expect to see calls "To:" any
of these aliases, and needs to delivery them appropriately to the user
as direct calls rather than as calls targeted originally to some other
user that have just been forwarded here. This might interact with
distinctive-ringing features, for example.

So there is applicability in both "UA-originated" and UA-terminated"
scenarios, and there is no requirement that the client be able to
cryptographically assert the identity associated with an inbound alias.

--
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 daemon@optimus.ietf.org  Tue May 28 15:44:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29022
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:44:26 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10852
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:44:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08942;
	Tue, 28 May 2002 15:25:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08896
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:25:05 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28337
	for <sip@ietf.org>; Tue, 28 May 2002 15:24:40 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNsd11763;
	Tue, 28 May 2002 14:23:54 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>,
        "'sip'" <sip@ietf.org>
Cc: "'Jonathan Rosemberg'" <jdrosen@dynamicsoft.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Subject: RE: [Sip] New version of the SIP over SCTP draft
Date: Tue, 28 May 2002 14:23:13 -0500
Message-ID: <00ad01c2067d$1ccb2830$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3CF3593D.E6C2FE86@lmf.ericsson.se>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Warning! There appears to be a revision numbering issue.

I have a file by the same name on the supplemental site which appears to
have been published last November.

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-sctp-01.txt

Which replaced

http://www.softarmor.com/sipwg/drafts/morgue/draft-ietf-sip-sctp-00.txt
published last August.

Perhaps the latest rev should be -02?

--
Dean



> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On 
> Behalf Of Gonzalo Camarillo
> Sent: Tuesday, May 28, 2002 5:18 AM
> To: sip
> Cc: Jonathan Rosemberg; Henning Schulzrinne
> Subject: [Sip] New version of the SIP over SCTP draft
> 
> 
> Hello,
> 
> I have just submitted a new version of the SIP over SCTP draft.
> 
http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sctp-01.txt

I have not changed anything. I have only updated the references (now
they are divided into normative and informative ones).

I am re-submitting this draft because its LC is scheduled for July, and
version 00 expires in May 2002 (i.e., right now).

Regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Tue May 28 15:45:19 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29042
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:45:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA10871
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:45:43 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08894;
	Tue, 28 May 2002 15:25:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08815
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:24:59 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28328;
	Tue, 28 May 2002 15:24:34 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SJNtd11766;
	Tue, 28 May 2002 14:23:55 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Christian Huitema'" <huitema@windows.microsoft.com>
Cc: <iesg@ietf.org>, <sip@ietf.org>
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 14:23:13 -0500
Message-ID: <00ae01c2067d$1d5abe00$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3CF3BEDE.4060703@cs.columbia.edu>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> > Shall we conclude that the SIP option should not be used in roaming 
> > scenarios? If that is the case, then we have a serious application 
> > domain restriction, which should be very clearly stated in the SIP 
> > option draft. If you actually want to address a roaming 
> scenario, then 
> > you have to describe how you are going to use IPSEC between 
> the server 
> > and the client, and how you are going to validate the IPSEC keys.
> 
> It would be helpful to have the 3G folks chime in here. 
> Realistically, 
> we aren't going to be developing new IPsec key distribution protocols 
> for this application, but 3G may already have to deliver a 
> shared secret 
> in a remote (away from home) environment.

In the 3GPP scenario, there is a security negotiation process used after
the default proxy is selected. This, within reasonable usage of the term
"assures", assures that the selected default proxy is within the trust
domain of the subscriber's home network.

Very roughly speaking, a piece of the AKA key is transferred along a
transititive IPSEC chain to the visited proxy, and the UA will not
achieve successful communication with the visited proxy unless it has
that key. 

This would seem to prevent proxy spoofing, within the limits imposed by
the transitive-trust model of 3GPP.

--
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 daemon@optimus.ietf.org  Tue May 28 15:47:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29116
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:47:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA11114
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:48:06 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10057;
	Tue, 28 May 2002 15:32:10 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10025
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:32:07 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28567
	for <sip@ietf.org>; Tue, 28 May 2002 15:31:41 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJX2YH025297;
	Tue, 28 May 2002 15:33:02 -0400 (EDT)
Message-ID: <3CF3DB0E.215085E3@dynamicsoft.com>
Date: Tue, 28 May 2002 15:31:26 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>, sip@ietf.org,
        rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <00b001c2067d$1e30aba0$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Dean Willis wrote:
> 
> Miguel said:
> > Jonathan said:
> > > Well, presumably some proxy will enforce the list of
> > associated-URI,
> > > and reject requests that have a value in the From field not amongst
> > > the allowed set? Is there a new response code for that?
> >
> > Yes, the proxy will send a 403 Forbidden. However, I don't
> > think this is
> > part of the scope of this I-D. I understand that the title
> > "Procedures at the proxy" are procedures related to the
> > extension (the header in this case). The idea in this I-D is
> > to convey to the UA the list of URIs that he can use
> > in subsequent requests, not how to police them. Therefore,
> > there are not procedures at the proxy related to the
> > P-Associated-URI header.
> 
> Actually, this policy enforcement is being made by the
> 3GPP-specific-back-to-back-user-agent-that-sometimes-acts-kindof-like-a-
> proxy called the P-CSCF. Documenting the behavior of this rather
> specalized node is probably far outside the scope of an IETF effort.
> Proxies, in general, are not expected to restrict the range of identity
> expression allowed to a user based on some sort of P-header. In fact,
> one might argue that proxies in general are PROHIBITED from doing this
> sort of thing . . .

Well, that enforcement IS being done, and I thought was core to the
entire concept here. Indeed, this is the essence of what I suggested for
the new applicability statement. My point is, if you are doing such
restrictions, you need to have a response code appropriate for this
error case.

I will also note that of all things proxies are doing these days,
rejecting a call because the From is not authorized is the least evil.
Indeed, one might argue that this is equivalent to sip level ingress
address filtering (RFC 2827), and is possibly a very good thing to do.

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Tue May 28 15:51:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29207
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 15:51:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA11422
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 15:52:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10167;
	Tue, 28 May 2002 15:32:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10131
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:32:39 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28598
	for <sip@ietf.org>; Tue, 28 May 2002 15:32:14 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJXZYH025300;
	Tue, 28 May 2002 15:33:35 -0400 (EDT)
Message-ID: <3CF3DB2F.E9D91D75@dynamicsoft.com>
Date: Tue, 28 May 2002 15:31:59 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'Michael Thomas'" <mat@cisco.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com,
        "'Miguel Garcia'" <Miguel.A.Garcia@ericsson.com>
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Dean Willis wrote:
> 
> > Michael Thomas wrote:
> > >
> > > So, I have a really dumb question. Why don't you
> > > limit the number of assertable identities by
> > > cryptographic means? That is, if I can't prove
> > > that I own an identity binding, it gets dumped
> > > on the floor?
> >
> > Sure; I think the issue (Miguel can correct me if I'm wrong),
> > is that the UA needs to be configured with the set of
> > identities it can claim in the first place. The same
> > credentials would allow the user to assert any one of those,
> > but the phone needs to know which it should present to the
> > user to use.
> 
> It goes a little further than this. We're also informing the UA of a
> number of extisting "aliases". The UA can expect to see calls "To:" any
> of these aliases, and needs to delivery them appropriately to the user
> as direct calls rather than as calls targeted originally to some other
> user that have just been forwarded here. This might interact with
> distinctive-ringing features, for example.

This isn't documented in the draft either, and needs to be.

-Jonathan R.


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

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



From daemon@optimus.ietf.org  Tue May 28 16:06:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29517
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 16:06:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA12676
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 16:07:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10720;
	Tue, 28 May 2002 15:42:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10693
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:42:21 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28913
	for <sip@ietf.org>; Tue, 28 May 2002 15:41:57 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SJhLYH025321;
	Tue, 28 May 2002 15:43:23 -0400 (EDT)
Message-ID: <3CF3DD7A.F6FFD98D@dynamicsoft.com>
Date: Tue, 28 May 2002 15:41:46 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tan Ya-Ching ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>
CC: "'adam@dynamicsoft.com'" <adam@dynamicsoft.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [SIP] NOTIFY request MUST contain an Expires header?
References: <5B4D0C5BA65ECA46969C1419122317E6E74DC8@mchh161e>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Tan Ya-Ching ICM N PG U ID A 1 wrote:
> 
> Thanks for the answer.
> 
> In that case, shouldn't the "expires" parameter in the
> Subscription-State
> header in NOTIFY carry the same MUST strength as for Expires header in
> 200
> OK response to SUBSCRIBE, instead of just a SHOULD (second last
> paragraph of
> 4.2.2 of draft-sip-events)? Section 4.2.4 'Subscriber NOTIFY Behavior'
> also
> talks about the "expires" parameter with "If the Subscription-State
> header
> also contains an "expires" parameter...", but what if it does not ? Can
> a
> NOTIFY request which matches (according to 4.3.4) the SUBSCRIBE request
> create a subscription and a new dialog if its Subscription-State does
> not
> contain an "expires" parameter ?

Yes, this is a good point. I believe this is probably an error in
sip-events, and that the expires parameter needs to be present with MUST
strength.

Adam?

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Tue May 28 16:17:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29724
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 16:17:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA13028
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 16:17:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11555;
	Tue, 28 May 2002 15:55:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11523
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 15:55:34 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29247
	for <sip@ietf.org>; Tue, 28 May 2002 15:55:10 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA29165;
	Tue, 28 May 2002 15:55:08 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SJt72i022456
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 28 May 2002 15:55:08 -0400 (EDT)
Message-ID: <3CF3E07E.3090403@cs.columbia.edu>
Date: Tue, 28 May 2002 15:54:38 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6
References: <3CF3BA6A.7090700@cs.columbia.edu> <3CF3D9D4.BFE306AC@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I'm happy to add this as another option, but I'm more than a bit afraid 
of further delaying progress on something which already has seen more 
than its share of delays. If we get stuck in general debates as to 
whether DHCP should be allowed at all, we'll get another decade or so, 
so there'll be plenty of time :-)

Jonathan Rosenberg wrote:
> 
> Henning Schulzrinne wrote:
> 
>>I agree that this would be useful, albeit a bit unusual compared to
>>other DHCP options. There are a few issues that would need to be
>>resolved:
>>
>>- Would this apply to v6 only? I don't know that the state of the v4
>>draft is in the IESG pipeline and what other "customers" there are. This
>>
>>would be the first DHCP option containing a URI, so this may cause some
>>broader issues.
> 
> 
> Understood. Its definitely not v6 specific. Maybe we need to define it
> separately because its too late or controversial. My main point is that
> technically, I think it is far superior to using IP addresses or domain
> names.
> 
> -Jonathan R.



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



From daemon@optimus.ietf.org  Tue May 28 17:08:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01171
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 17:08:30 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA17454
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:08:55 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15179;
	Tue, 28 May 2002 16:41:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15102
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 16:41:52 -0400 (EDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00588;
	Tue, 28 May 2002 16:41:26 -0400 (EDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 13:41:19 -0700
Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 13:41:19 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 13:41:18 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 13:41:18 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0);
	 Tue, 28 May 2002 13:41:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 13:41:18 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E53A@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
thread-index: AcIGfTd3vsQjOe91RASdqO6Xm4cI4QACjkEQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Dean Willis" <dean.willis@softarmor.com>, <iesg@ietf.org>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 28 May 2002 20:41:17.0765 (UTC) FILETIME=[0452CF50:01C20688]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA15113
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> Christian wrote:
> > I have a major issue with this spec, namely that the security
> > problems are not addressed. The security section correctly
> > lists one of the main security threats, the spoofing of a DHCP
server:
> 
> Yes, this is a real issue.
> 
> But isn't this sort of a general DHCP problem rather than one specific
> to the usage of SIP?
> 
> Do we need to bascially stop using DHCP while working on it, and if so
> is this (SIP working group) the right forum to try and tackle that?

Well, there is a middle ground, which is to only use DHCP when the
risk/benefit ratio is right. My contention is that, in the case of SIP,
the risk/benefit ratio is weighted a lot towards risk, and that in
general there are other solutions. For example, we know that the UA must
have some explicit configuration -- reference URL, security credentials,
etc. In these cases, using DHCP for SIP is not needed.

-- Christian Huitema

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



From daemon@ns.ietf.org  Tue May 28 17:34:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01756
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 17:34:04 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA19336
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:34:29 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17842;
	Tue, 28 May 2002 17:18:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17768
	for <sip@ns.ietf.org>; Tue, 28 May 2002 17:18:18 -0400 (EDT)
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01384;
	Tue, 28 May 2002 17:17:52 -0400 (EDT)
Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA15553;
	Tue, 28 May 2002 17:18:15 -0400 (EDT)
Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46])
	(authenticated bits=0)
	by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g4SLIE2i026056
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT);
	Tue, 28 May 2002 17:18:14 -0400 (EDT)
Message-ID: <3CF3F3F8.6050502@cs.columbia.edu>
Date: Tue, 28 May 2002 17:17:44 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: Dean Willis <dean.willis@softarmor.com>, iesg@ietf.org, sip@ietf.org
Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
References: <F66A04C29AD9034A8205949AD0C9010401C0E53A@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> have some explicit configuration -- reference URL, security credentials,
> etc. In these cases, using DHCP for SIP is not needed.

I don't think that is true. In a visited network, the outbound proxy may 
be needed to communicate, as I mentioned in my previous email.

Plus, I don't see that the SIP case is so special. If I spoof a DHCP 
server (absent of a shared secret), I can hand out bogus IP addresses 
that conveniently end up sending all packets to the default router for 
that address (another compromised server). Why bother with just received 
S/MIME encrypted SIP requests if I can get the whole hog?

I don't know which of the DHCP IPv4 options will find its way into v6, 
but the POP server option, the NNTP server option and NIS+ options seem 
to be at least as juicy a target.

I'm all for a stronger applicability statement, but this would seem to 
apply to DHCPv6 in general. Basically, it would have to say "DHCPv6 is 
not currently suited for roaming users that don't have a pre-established 
secret with the visited domain".

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 daemon@ns.ietf.org  Tue May 28 17:39:29 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01888
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 17:39:29 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA19639
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:39:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17682;
	Tue, 28 May 2002 17:16:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA17650
	for <sip@optimus.ietf.org>; Tue, 28 May 2002 17:16:33 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01339
	for <sip@ietf.org>; Tue, 28 May 2002 17:16:03 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SLFlHs010648;
	Tue, 28 May 2002 14:15:47 -0700 (PDT)
Received: from imop.cisco.com (localhost.cisco.com [127.0.0.1])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with SMTP id AAE98372 (AUTH rmahy);
	Tue, 28 May 2002 14:15:46 -0700 (PDT)
Message-Id: <200205282115.AAE98372@imop.cisco.com>
Received: from 171.68.225.134
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with HTTP/1.0;
	Tue, 28 May 2002 14:21:06 -0700
Date: Tue, 28 May 2002 14:21:06 -0700
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [Sip] new I-D for registration event package
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: sip@ietf.org
X-Mailer: Mirapoint Webmail Direct 3.1.0.54-GA
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

As a point of process, if this work is adopted as a WG effort,
it  probably belongs in SIPPING or in SIMPLE.

thanks,
-rohan


---- Original message ----
>Date: Tue, 28 May 2002 02:14:41 -0400
>From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>  
>Subject: [Sip] new I-D for registration event package  
>To: sip@ietf.org
>
>Folks,
>
>I've just submitted draft-rosenberg-sip-reg-event to the
archives. Until
>it appears you can pick up a copy at:
>
>http://www.jdrosen.net/papers/draft-rosenberg-sip-reg-event-00.txt
>
>This draft is an attempt to generalize the registration event
package
>defined in:
>
>http://www.ietf.org/internet-drafts/draft-beckmann-sip-reg-event-01.txt
>
>I believe there are a lot of valuable applications for a
registration
>event package, and therefore, having a generalized version
seems like a
>good thing. There is nothing radically different between the
two drafts.
>The main difference is that mine defines a specific state
machine for
>registration events, and defines an XML document format to
specifically
>convey information about changes to that machine. It doesn't
reuse the
>presence document format, as the beckmann draft does. My
draft does
>appear to meet the 3gpp requirements. 
>
>The key decision point for the group is whether to move
forward with
>draft-rosenberg-sip-reg-event (as a sipwg draft) or
>draft-beckmann-sip-reg-event. Unfortunately, the timeline
doesn't change
>in either case, since something is needed for 3gpp in quite
short order.
>In some private email conversations, Mark and Georg indicated
support
>for going with a generalized version, but I will let them
speak for
>themselves.
>
>Thanks,
>Jonathan R.
>-- 
>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>Chief Scientist                         First Floor
>dynamicsoft                             East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
>http://www.jdrosen.net                  PH:  (973) 952-5000
>http://www.dynamicsoft.com
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 daemon@ns.ietf.org  Tue May 28 17:50:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02187
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 17:50:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA20725
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:51:03 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19010;
	Tue, 28 May 2002 17:31:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18935
	for <sip@ns.ietf.org>; Tue, 28 May 2002 17:31:23 -0400 (EDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01675;
	Tue, 28 May 2002 17:30:56 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 14:30:41 -0700
Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 14:30:41 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 14:30:41 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 14:30:41 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0);
	 Tue, 28 May 2002 14:30:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 14:30:40 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E53C@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
thread-index: AcIGjS+2GDNY1FuZQKi3FxZUgcKaogAAP++g
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Dean Willis" <dean.willis@softarmor.com>, <iesg@ietf.org>, <sip@ietf.org>
X-OriginalArrivalTime: 28 May 2002 21:30:40.0007 (UTC) FILETIME=[E9F51170:01C2068E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA18938
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> I don't know which of the DHCP IPv4 options will find its way into v6,
> but the POP server option, the NNTP server option and NIS+ options
seem
> to be at least as juicy a target.

It is unclear whether we need DHCPv6 at all. We definitely don't need it
for address allocation, or to find the local gateway, but a "DHCP
INFORM" procedure may be a useful way to convey some network parameters,
such as the address of the local DNS server. OTOH, I don't believe that
existing mail clients use DHCP to find out the address of their mail
server; just because a DHCP option is defined does not means that it
gets used...

> I'm all for a stronger applicability statement, but this would seem to
> apply to DHCPv6 in general. Basically, it would have to say "DHCPv6 is
> not currently suited for roaming users that don't have a
pre-established
> secret with the visited domain".

Yes, that would certainly be a reasonable first step. But I still
believe that we have to give up the whole idea of discovering SIP
proxies on the fly. To me, this looks like a ludicrous attempt to
recreate the phone architecture on top of IP.

-- Christian Huitema

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



From daemon@ns.ietf.org  Tue May 28 17:50:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02204
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 17:50:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA20739
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:51:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19279;
	Tue, 28 May 2002 17:34:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19173
	for <sip@ns.ietf.org>; Tue, 28 May 2002 17:34:10 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01749
	for <sip@ietf.org>; Tue, 28 May 2002 17:33:44 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLWl412739;
	Tue, 28 May 2002 16:32:47 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: "'sip'" <sip@ietf.org>
Cc: <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        "Jon Peterson \(jon.peterson@NeuStar.com\)" <jon.peterson@neustar.biz>
Date: Tue, 28 May 2002 16:32:06 -0500
Message-ID: <00d901c2068f$1e0b4420$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for draft-ietf-sip-privacy-general
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


We need to do a quick review of the general privacy draft developed out
of our discussion in Las Vegas.

Please send any issues to the list and the editor IMMEDIATELY.

The draft is available from:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.
html
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.
txt
And soon to be available from internet-drafts if not already . . .


--
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 daemon@ns.ietf.org  Tue May 28 17:53:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02285
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 17:53:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA21073
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 17:53:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19163;
	Tue, 28 May 2002 17:34:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19126
	for <sip@ns.ietf.org>; Tue, 28 May 2002 17:34:06 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01747
	for <sip@ietf.org>; Tue, 28 May 2002 17:33:40 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLWl412740;
	Tue, 28 May 2002 16:32:47 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'sip'" <sip@ietf.org>
Cc: <brian.rosen@marconi.com>, <rohan@cisco.com>, <jo@ipdialog.com>,
        "'Cullen Jennings'" <fluffy@cisco.com>
Date: Tue, 28 May 2002 16:32:06 -0500
Message-ID: <00da01c2068f$1e0e5160$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


We need to do a quick working group last call on the "Asserted Identity"
draft.

Please submit comments to the list and draft editor IMMEDIATELY.

Draft available from:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0
0.html
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0
0.txt

And soon to be in the internet-drafts archive.

--
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 daemon@ns.ietf.org  Tue May 28 18:07:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02560
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 18:07:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA22657
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:07:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20294;
	Tue, 28 May 2002 17:47:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20260
	for <sip@ns.ietf.org>; Tue, 28 May 2002 17:47:28 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02082
	for <sip@ietf.org>; Tue, 28 May 2002 17:47:01 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLk7412846;
	Tue, 28 May 2002 16:46:07 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>, <sip@ietf.org>,
        <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>
Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
Date: Tue, 28 May 2002 16:45:24 -0500
Message-ID: <00dd01c20690$fac7a380$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <3CF3DB0E.215085E3@dynamicsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> > Actually, this policy enforcement is being made by the
> > 
> 3GPP-specific-back-to-back-user-agent-that-sometimes-acts-kindof-like-
> > a-
> > proxy called the P-CSCF. Documenting the behavior of this rather
> > specalized node is probably far outside the scope of an IETF effort.
> > Proxies, in general, are not expected to restrict the range 
> of identity
> > expression allowed to a user based on some sort of 
> P-header. In fact,
> > one might argue that proxies in general are PROHIBITED from 
> doing this
> > sort of thing . . .
> 
> Well, that enforcement IS being done, and I thought was core 
> to the entire concept here. Indeed, this is the essence of 
> what I suggested for the new applicability statement. My 
> point is, if you are doing such restrictions, you need to 
> have a response code appropriate for this error case.
> 
> I will also note that of all things proxies are doing these 
> days, rejecting a call because the From is not authorized is 
> the least evil. Indeed, one might argue that this is 
> equivalent to sip level ingress address filtering (RFC 2827), 
> and is possibly a very good thing to do.

I'm not saying that proxies can't do ingress filtering, just that
standardizing this behavior based on a P-header seems a  bit iffy from a
"SIP Change Process" perspective.

--
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 daemon@ns.ietf.org  Tue May 28 18:09:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02619
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 18:09:16 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA22875
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:09:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20543;
	Tue, 28 May 2002 17:49:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20467
	for <sip@ns.ietf.org>; Tue, 28 May 2002 17:49:30 -0400 (EDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02136;
	Tue, 28 May 2002 17:49:03 -0400 (EDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 14:48:56 -0700
Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 14:48:56 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 14:48:56 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 14:48:55 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0);
	 Tue, 28 May 2002 14:48:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 14:48:55 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C901040327050B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
thread-index: AcIGkScDYvSrcbgxQMWy40LRJj85owAAB7Hw
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: <iesg@ietf.org>, <sip@ietf.org>
X-OriginalArrivalTime: 28 May 2002 21:48:55.0533 (UTC) FILETIME=[76F111D0:01C20691]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA20470
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> If you have a better approach for discovering the SIP proxy
controlling
> the firewall that you didn't know that you were behind (and I'd argue
> that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot
said,
> "all ears" . . .

Could it be that this "sip proxy controlling the firewall" is part of
the problem rather than part of the solution? It is certainly not part
of the IP architecture...

-- Christian Huitema

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



From daemon@ns.ietf.org  Tue May 28 18:20:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02915
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 18:20:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA23586
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:20:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22240;
	Tue, 28 May 2002 18:02:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22209
	for <sip@ns.ietf.org>; Tue, 28 May 2002 18:02:54 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02480
	for <sip@ietf.org>; Tue, 28 May 2002 18:02:28 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SM0SYH025772;
	Tue, 28 May 2002 18:00:29 -0400 (EDT)
Message-ID: <3CF3FD9D.1D5C6489@dynamicsoft.com>
Date: Tue, 28 May 2002 17:58:53 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: Dean Willis <dean.willis@softarmor.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>, sip@ietf.org
Subject: Re: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
References: <F66A04C29AD9034A8205949AD0C901040327050B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Christian Huitema wrote:
> 
> > If you have a better approach for discovering the SIP proxy
> controlling
> > the firewall that you didn't know that you were behind (and I'd argue
> > that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot
> said,
> > "all ears" . . .
> 
> Could it be that this "sip proxy controlling the firewall" is part of
> the problem rather than part of the solution? It is certainly not part
> of the IP architecture...

In theory, I agree with you Christian, in that the whole notion of a
visited proxy is silly; after all, when I'm in a hotel, I still connect
to the same mail server back in my "home", and not a local hotel mail
server which I discovered through DHCP. 

However, for communications services, local outbound proxies native to a
visited domain do and will exist for many reasons (for example, local
dialing plans, 911, local services, etc.), only one of which is firewall
traversal.

-Jonathan R.

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

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



From daemon@ns.ietf.org  Tue May 28 18:21:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02953
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 18:21:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA23665
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:21:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22090;
	Tue, 28 May 2002 18:01:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22055
	for <sip@ns.ietf.org>; Tue, 28 May 2002 18:01:32 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02468
	for <sip@ietf.org>; Tue, 28 May 2002 18:01:06 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.70])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4SM1nYH025781;
	Tue, 28 May 2002 18:01:49 -0400 (EDT)
Message-ID: <3CF3FDEE.FEB7A29C@dynamicsoft.com>
Date: Tue, 28 May 2002 18:00:14 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Conclusion of WGLC, Call for IETF Last Call on sip-dhcpv6
References: <3CF3E07E.3090403@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I am fine to pursue this separately, and let the existing work continue.

-Jonathan R.

Henning Schulzrinne wrote:
> 
> I'm happy to add this as another option, but I'm more than a bit afraid
> of further delaying progress on something which already has seen more
> than its share of delays. If we get stuck in general debates as to
> whether DHCP should be allowed at all, we'll get another decade or so,
> so there'll be plenty of time :-)
> 
> Jonathan Rosenberg wrote:
> >
> > Henning Schulzrinne wrote:
> >
> >>I agree that this would be useful, albeit a bit unusual compared to
> >>other DHCP options. There are a few issues that would need to be
> >>resolved:
> >>
> >>- Would this apply to v6 only? I don't know that the state of the v4
> >>draft is in the IESG pipeline and what other "customers" there are.
> This
> >>
> >>would be the first DHCP option containing a URI, so this may cause
> some
> >>broader issues.
> >
> >
> > Understood. Its definitely not v6 specific. Maybe we need to define it
> > separately because its too late or controversial. My main point is
> that
> > technically, I think it is far superior to using IP addresses or
> domain
> > names.
> >
> > -Jonathan R.

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

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



From daemon@ns.ietf.org  Tue May 28 18:27:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03064
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 18:27:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA23957
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:28:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22417;
	Tue, 28 May 2002 18:04:42 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22345
	for <sip@ns.ietf.org>; Tue, 28 May 2002 18:04:38 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02490;
	Tue, 28 May 2002 18:04:12 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4SM3XIZ006540;
	Tue, 28 May 2002 15:03:33 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABT15067;
	Tue, 28 May 2002 15:00:34 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA06061; Tue, 28 May 2002 15:03:32 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15603.65204.125284.667726@thomasm-u1.cisco.com>
Date: Tue, 28 May 2002 15:03:32 -0700 (PDT)
To: "Christian Huitema" <huitema@windows.microsoft.com>
Cc: "Dean Willis" <dean.willis@softarmor.com>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>, <iesg@ietf.org>,
        <sip@ietf.org>
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
In-Reply-To: <F66A04C29AD9034A8205949AD0C901040327050B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
References: <F66A04C29AD9034A8205949AD0C901040327050B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Christian Huitema writes:
 > > If you have a better approach for discovering the SIP proxy
 > controlling
 > > the firewall that you didn't know that you were behind (and I'd argue
 > > that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot
 > said,
 > > "all ears" . . .
 > 
 > Could it be that this "sip proxy controlling the firewall" is part of
 > the problem rather than part of the solution? It is certainly not part
 > of the IP architecture...

   <applause>

		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 daemon@ns.ietf.org  Tue May 28 18:35:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03223
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 18:35:06 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA24634
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:35:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23330;
	Tue, 28 May 2002 18:15:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23299
	for <sip@ns.ietf.org>; Tue, 28 May 2002 18:15:21 -0400 (EDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02749
	for <sip@ietf.org>; Tue, 28 May 2002 18:14:55 -0400 (EDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 15:14:48 -0700
Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 15:14:48 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 15:14:47 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 15:14:47 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0);
	 Tue, 28 May 2002 15:14:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 15:14:45 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E53D@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
thread-index: AcIGkvTnn9uu/+9PTqWseqwkJO/JAAAAIcqg
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: "Dean Willis" <dean.willis@softarmor.com>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>, <sip@ietf.org>
X-OriginalArrivalTime: 28 May 2002 22:14:47.0429 (UTC) FILETIME=[13F19B50:01C20695]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA23300
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> In theory, I agree with you Christian, in that the whole notion of a
> visited proxy is silly; after all, when I'm in a hotel, I still
connect
> to the same mail server back in my "home", and not a local hotel mail
> server which I discovered through DHCP.
>
> However, for communications services, local outbound proxies native to
a
> visited domain do and will exist for many reasons (for example, local
> dialing plans, 911, local services, etc.), only one of which is
firewall
> traversal.

I don't think that the "firewall traversal" requirement actually applies
to hotel connections. The hotel connection supposedly gives you a high
speed Internet access, and they often charge you good money for the
service. The hotel has no good reason to check whether you use TCP or
UDP, or for that matter IPSEC -- and since we are speaking of a DHCPv6
option, we have to assume that we are using IPv6, and that there is no
NAT to go through. In these conditions, the only real reason for the
local proxy is a desire to control some specific applications -- very
possibly, make you pay phone calls by the minute. As you say, this is
silly, and I don't see why we should tweak our standards encourage such
silliness.

Now, if what you want is to discover the local 911 service, you probably
don't want to use an insecure channel. Which would prevent using DHCPv6,
since it is not secure in a roaming scenario...

-- Christian Huitema

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



From daemon@ns.ietf.org  Tue May 28 18:57:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02558
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 18:07:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA22661
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 18:07:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20246;
	Tue, 28 May 2002 17:47:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA20164
	for <sip@ns.ietf.org>; Tue, 28 May 2002 17:47:13 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02073;
	Tue, 28 May 2002 17:46:45 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SLk5412840;
	Tue, 28 May 2002 16:46:05 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: <iesg@ietf.org>, <sip@ietf.org>
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 16:45:24 -0500
Message-ID: <00db01c20690$f99c1bd0$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010401C0E53C@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

 
> Yes, that would certainly be a reasonable first step. But I 
> still believe that we have to give up the whole idea of 
> discovering SIP proxies on the fly. To me, this looks like a 
> ludicrous attempt to recreate the phone architecture on top of IP.

I suppose we could use multicast or v6-anycast with a standardized
service address, but that would seem to have the same security issues as
DHCP. . .

If you have a better approach for discovering the SIP proxy controlling
the firewall that you didn't know that you were behind (and I'd argue
that Universal-Plug-and-Pray may not qualify), I'm, as Ross Perot said,
"all ears" . . .

In the meantime, I have to manually reconfigure MS-Messenger every time
I go from my house to my office or back. It gets tedious.


--
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 daemon@ns.ietf.org  Tue May 28 19:03:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03728
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 19:03:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA25919
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:03:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24825;
	Tue, 28 May 2002 18:40:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA24792
	for <sip@ns.ietf.org>; Tue, 28 May 2002 18:40:05 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03323
	for <sip@ietf.org>; Tue, 28 May 2002 18:39:39 -0400 (EDT)
Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SMdOHs003900;
	Tue, 28 May 2002 15:39:24 -0700 (PDT)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id ABT16067;
	Tue, 28 May 2002 15:36:24 -0700 (PDT)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA06068; Tue, 28 May 2002 15:39:22 -0700 (PDT)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15604.1818.608100.513991@thomasm-u1.cisco.com>
Date: Tue, 28 May 2002 15:39:22 -0700 (PDT)
To: "Dean Willis" <dean.willis@softarmor.com>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Michael Thomas'" <mat@cisco.com>, <sip@ietf.org>, <rohan@cisco.com>,
        <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        "'Miguel Garcia'" <Miguel.A.Garcia@ericsson.com>
Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
In-Reply-To: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2>
References: <3CF3AEF9.EF57314C@dynamicsoft.com>
	<00b101c2067d$1e940150$1d036e3f@TXDWILLIS2>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Dean Willis writes:
 > > Michael Thomas wrote:
 > > > 
 > > > So, I have a really dumb question. Why don't you
 > > > limit the number of assertable identities by
 > > > cryptographic means? That is, if I can't prove
 > > > that I own an identity binding, it gets dumped
 > > > on the floor?
 > > 
 > > Sure; I think the issue (Miguel can correct me if I'm wrong), 
 > > is that the UA needs to be configured with the set of 
 > > identities it can claim in the first place. The same 
 > > credentials would allow the user to assert any one of those, 
 > > but the phone needs to know which it should present to the 
 > > user to use.
 > 
 > It goes a little further than this. We're also informing the UA of a
 > number of extisting "aliases". The UA can expect to see calls "To:" any
 > of these aliases, and needs to delivery them appropriately to the user
 > as direct calls rather than as calls targeted originally to some other
 > user that have just been forwarded here. This might interact with
 > distinctive-ringing features, for example.
 > 
 > So there is applicability in both "UA-originated" and UA-terminated"
 > scenarios, and there is no requirement that the client be able to
 > cryptographically assert the identity associated with an inbound alias.

Ok, I guess my next dumb question is whether we
really want to go down the slippery slope of
turning SIP into a provisioning protocol. As in,
why stop here and what delimits this case with, oh
say, sending down which distinctive ringing tone
to associate with which identity? In your example,
the UA wouldn't have any clue how to do what you
said unless it had that binding...

	      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 daemon@ns.ietf.org  Tue May 28 19:32:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04079
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 19:32:40 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA27590
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:33:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26502;
	Tue, 28 May 2002 19:12:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26413
	for <sip@ns.ietf.org>; Tue, 28 May 2002 19:12:33 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03854;
	Tue, 28 May 2002 19:11:53 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SNBG413414;
	Tue, 28 May 2002 18:11:16 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Cc: <iesg@ietf.org>, <sip@ietf.org>
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 18:10:34 -0500
Message-ID: <011301c2069c$df838b00$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <F66A04C29AD9034A8205949AD0C901040327050B@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> Could it be that this "sip proxy controlling the firewall" is 
> part of the problem rather than part of the solution? It is 
> certainly not part of the IP architecture...
> 
> -- Christian Huitema

Yes, I'm sure that dealing with reality is out-of-scope for our
architecture. That's why we've been so successful at curtailing the
spread of NAT and firewall boxes and assuring interoperability when they
do spontaneously appear.

Your argument, while principaled, is consistent with the declaration
that since cars are approximately two horses wide (see "The Standard
that Wouldn't Die") we should be able to feed them grain, steer them
with reins and control their velocity with a buggy whip.

--
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 daemon@ns.ietf.org  Tue May 28 19:34:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04096
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 19:34:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA27676
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:34:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26380;
	Tue, 28 May 2002 19:12:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26343
	for <sip@ns.ietf.org>; Tue, 28 May 2002 19:12:24 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03857
	for <sip@ietf.org>; Tue, 28 May 2002 19:11:59 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SNBF413411;
	Tue, 28 May 2002 18:11:15 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>, <sip@ietf.org>
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 18:10:34 -0500
Message-ID: <011201c2069c$df496830$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <F66A04C29AD9034A8205949AD0C9010401C0E53D@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Christian said:
> I don't think that the "firewall traversal" requirement 
> actually applies to hotel connections. The hotel connection 
> supposedly gives you a high speed Internet access, and they 
> often charge you good money for the service. The hotel has no 
> good reason to check whether you use TCP or UDP, or for that 
> matter IPSEC -- and since we are speaking of a DHCPv6 option, 
> we have to assume that we are using IPv6, and that there is 
> no NAT to go through. In these conditions, the only real 
> reason for the local proxy is a desire to control some 
> specific applications -- very possibly, make you pay phone 
> calls by the minute. As you say, this is silly, and I don't 
> see why we should tweak our standards encourage such silliness.


Where are you finding hotels with broadband that don't require use of
their NAT box and HTTP proxy? I've never seen a hotel with a truly open
internet connection.

-
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 daemon@ns.ietf.org  Tue May 28 19:36:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04130
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 19:36:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id TAA27723
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 19:36:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26405;
	Tue, 28 May 2002 19:12:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26341
	for <sip@ns.ietf.org>; Tue, 28 May 2002 19:12:23 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03856
	for <sip@ietf.org>; Tue, 28 May 2002 19:11:58 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4SNBF413408;
	Tue, 28 May 2002 18:11:15 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Michael Thomas'" <mat@cisco.com>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, <sip@ietf.org>,
        <rohan@cisco.com>, <brian.rosen@marconi.com>, <jo@ipdialog.com>,
        "'Miguel Garcia'" <Miguel.A.Garcia@ericsson.com>
Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
Date: Tue, 28 May 2002 18:10:34 -0500
Message-ID: <011101c2069c$df0ab180$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <15604.1818.608100.513991@thomasm-u1.cisco.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

MAT asked:
> Ok, I guess my next dumb question is whether we
> really want to go down the slippery slope of
> turning SIP into a provisioning protocol. As in,
> why stop here and what delimits this case with, oh
> say, sending down which distinctive ringing tone
> to associate with which identity? In your example,
> the UA wouldn't have any clue how to do what you
> said unless it had that binding...

That, my friend, is why it's a P-header and not a standard extension. 

The assosiated-URI's-associated-ringing-tone-selector idea is pretty
clever. Why don't you write up a P-header draft and submit it? Odds are
it makes it into Release-6 :-) (I smile, but do not jest).

--
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 daemon@ns.ietf.org  Tue May 28 20:21:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04826
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 20:21:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id UAA29804
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 20:22:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28574;
	Tue, 28 May 2002 19:53:50 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28000
	for <sip@ns.ietf.org>; Tue, 28 May 2002 19:42:42 -0400 (EDT)
Received: from dsl-64-192-31-101.telocity.com (dsl-64-192-31-101.telocity.com [64.192.31.101])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04273
	for <sip@ietf.org>; Tue, 28 May 2002 19:42:17 -0400 (EDT)
Received: from keyser1.dsl-64-192-31-101.telocity.com ([192.168.0.1])
          by dsl-64-192-31-101.telocity.com (JAMES SMTP Server 2.0a2) with SMTP ID 102
          for <sip@ietf.org>;
          Tue, 28 May 2002 19:42:06 -0400
Received: from jeff (unverified [192.168.0.18]) by KEYSER1.dsl-64-192-31-101.telocity.com
 (EMWAC SMTPRS 0.83) with SMTP id <B0000011266@KEYSER1.dsl-64-192-31-101.telocity.com>;
 Tue, 28 May 2002 19:41:30 -0400
From: "Jeff Keyser" <JKeyser@telocity.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "'SIP Mailing List \(E-mail\)'" <sip@ietf.org>
Subject: RE: [Sip] Comment on draft-ietf-sip-rfc2543bis-09
Date: Tue, 28 May 2002 19:41:28 -0400
Message-ID: <000001c206a1$30ca97c0$1200a8c0@dsl6419231101.telocity.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3CF3192F.CCB8076F@dynamicsoft.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Thanks for the clarification.  Perhaps this reasoning should be explicitly
stated in the document, since I apparently wasn't the only person who was
confused by this.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tuesday, May 28, 2002 1:44 AM
> To: Jeff Keyser
> Cc: SIP Mailing List (E-mail)
> Subject: Re: [Sip] Comment on draft-ietf-sip-rfc2543bis-09
>
>
> inline.
>
> Jeff Keyser wrote:
> >
> > I apologize if this is not the correct place for this
> comment.  If this
> > is
> > not, please let me know where I should direct this.
> >
> > I am working with draft-ietf-sip-rfc2543bis-09 to write a
> SIP client,
> > and
> > the INVITE transactions of section 17 don't make sense to
> me as written.
> > For both client and server INVITE transactions in the
> "Proceeding" state
> > (and "Calling" state for client transactions), if a new
> response status
> > code
> > is 300-699, the transaction changes to the "Completed"
> state; and, if a
> > new
> > response status code is 2xx, the transaction changes to the
> "Terminated"
> > state.  The state diagrams show this same logic.
> >
> > I assume that this is supposed to be the other way around, since the
> > "Completed" state is used the handle the ACK request of a connected
> > call.
>
> No, it is correct as written.
>
> The reason is that this state machine represents the *transaction*
> state. The transaction state machine is responsible for
> request/response
> correlation, retransmissions, and so on. It is NOT responsible for the
> management of the call state. When a 2xx is received, the
> transaction is
> complete. There is an ACK, but this ACK constitutes a separate
> transaction. Correlation of the ACK with the 2xx is done by
> the UAS at a
> higher layer, not by the transaction machines. In contrast,
> for non-2xx
> final responses, the ACK is part of the same transaction, and so the
> state machine must stick around to handle that.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com


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



From daemon@ns.ietf.org  Tue May 28 22:50:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07737
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 22:50:26 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA08878
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 22:50:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04943;
	Tue, 28 May 2002 21:57:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04886
	for <sip@ns.ietf.org>; Tue, 28 May 2002 21:57:51 -0400 (EDT)
Received: from sict.ac.cn ([210.72.128.8])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06601
	for <sip@ietf.org>; Tue, 28 May 2002 21:57:26 -0400 (EDT)
Received: from guy ([210.72.128.47])
        by sict.ac.cn (Merak 4.10.020) with SMTP id 5105A6C8
        for <sip@ietf.org>; Wed, 29 May 2002 09:56:16 +0800
MIME-Version: 1.0
Message-Id: <3CF436D8.00000A.00748@guy>
Date: Wed, 29 May 2002 10:03:04 +0800
Content-Type: Multipart/related;
  type="multipart/alternative";
  boundary="------------Boundary-00=_4DOUH890000000000000"
X-Mailer: IncrediMail 2001 (1750690)
From: "Guy" <ligang@sict.ac.cn>
X-FID: BA285063-5BCE-11D4-AF8D-0050DAC67E11
X-FVER: 2.0
X-FIT: Letter
X-FCOL: Elegant Paper
X-FCAT: Stationery
X-FDIS: Rice Fields
X-Extensions: SU1CTDEsNDEsgUmBSTAkkcGNgZmVTY0wNCxNhYUoiU0kOMEoTYGBjYEoJDSZnSyFhUksSU1CTDIsMCwsSU1CTDMsMCws
X-BG: <BC9950CD-011B-49F3-93FB-F4268D3048D5>
X-BGT: repeat
X-BGC: #dce0e3
X-BGPX: 0px
X-BGPY: 0px
X-ASN: ANIM3D00-NONE-0000-0000-000000000000
X-ASNF: 0
X-ASH: ANIM3D00-NONE-0000-0000-000000000000
X-ASHF: 1
X-AN: 6486DDE0-3EFD-11D4-BA3D-0050DAC68030
X-ANF: 0
X-AP: 6486DDE0-3EFD-11D4-BA3D-0050DAC68030
X-APF: 1
X-AD: C3C52140-4147-11D4-BA3D-0050DAC68030
X-ADF: 0
X-AUTO: X-ASN,X-ASH,X-AN,X-AP,X-AD
X-CNT: ;
X-Priority: 3
To: <sip@ietf.org>
Subject: [Sip] About BYE and CANCEL
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


--------------Boundary-00=_4DOUH890000000000000
Content-Type: Multipart/Alternative;
  boundary="------------Boundary-00=_4DOUCJD0000000000000"


--------------Boundary-00=_4DOUCJD0000000000000
Content-Type: Text/Plain;
  charset="gb2312"
Content-Transfer-Encoding: quoted-printable

I want to know the scenario when the UA should send BYE or CANCEL.=0D
=46rom RFC2543,CANCEL is only used to terminate the pending request.=0D
My question is : whether BYE request also can terminate the pending reque=
st
or not?=0D
Best regards!!=0D
=0D
=0D
Guy=0D
Email:  ligang@sict.ac.cn
--------------Boundary-00=_4DOUCJD0000000000000
Content-Type: Text/HTML;
  charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312"=
><html>
<head>
<meta name=3D"GENERATOR" content=3D"IncrediMail 1.0">=0D
<!--IncrdiXMLRemarkStart>
<IncrdiX-Info>
<X-FID>BA285063-5BCE-11D4-AF8D-0050DAC67E11</X-FID>
<X-FVER>2.0</X-FVER>
<X-FIT>Letter</X-FIT>
<X-FCOL>Elegant Paper</X-FCOL>
<X-FCAT>Stationery</X-FCAT>
<X-FDIS>Rice Fields</X-FDIS>
<X-Extensions>SU1CTDEsNDEsgUmBSTAkkcGNgZmVTY0wNCxNhYUoiU0kOMEoTYGBjYEoJDS=
ZnSyFhUksSU1CTDIsMCwsSU1CTDMsMCws</X-Extensions>
<X-BG>BC9950CD-011B-49F3-93FB-F4268D3048D5</X-BG>
<X-BGT>repeat</X-BGT>
<X-BGC>#dce0e3</X-BGC>
<X-BGPX>0px</X-BGPX>
<X-BGPY>0px</X-BGPY>
<X-ASN>ANIM3D00-NONE-0000-0000-000000000000</X-ASN>
<X-ASNF>0</X-ASNF>
<X-ASH>ANIM3D00-NONE-0000-0000-000000000000</X-ASH>
<X-ASHF>1</X-ASHF>
<X-AN>6486DDE0-3EFD-11D4-BA3D-0050DAC68030</X-AN>
<X-ANF>0</X-ANF>
<X-AP>6486DDE0-3EFD-11D4-BA3D-0050DAC68030</X-AP>
<X-APF>1</X-APF>
<X-AD>C3C52140-4147-11D4-BA3D-0050DAC68030</X-AD>
<X-ADF>0</X-ADF>
<X-AUTO>X-ASN,X-ASH,X-AN,X-AP,X-AD</X-AUTO>
<X-CNT>;</X-CNT>
</IncrdiX-Info>
<IncrdiXMLRemarkEnd-->
=0A</head>
<BODY style=3D"BACKGROUND-POSITION: 0px 0px; BACKGROUND-REPEAT: repeat; F=
ONT-FAMILY: Comic Sans MS; FONT-SIZE: 12pt; MARGIN: 0px 10px 10px" text=3D=
#000040 bgColor=3D#dce0e3 background=3Dcid:BC9950CD-011B-49F3-93FB-F4268D=
3048D5 scroll=3D"yes" X-FIT=3D"Letter" X-FCAT=3D"Elegant Paper" X-FCOL=3D=
"Elegant Paper" X-FDIS=3D"Rice Fields" X-FID=3D"BA285063-5BCE-11D4-AF8D-0=
050DAC67E11" X-FVER=3D"2.0" X-ASN=3D"ANIM3D00-NONE-0000-0000-000000000000=
" X-ASNF=3D"0" X-ASH =3D"ANIM3D00-NONE-0000-0000-000000000000" X-ASHF =3D=
"1" X-AN =3D"6486DDE0-3EFD-11D4-BA3D-0050DAC68030" X-ANF=3D"0" X-AP=3D"64=
86DDE0-3EFD-11D4-BA3D-0050DAC68030" X-APF=3D"1" X-AD=3D"C3C52140-4147-11D=
4-BA3D-0050DAC68030" X-ADF=3D"0" SIGCOLOR=3D"0" ORGYPOS=3D"0"><TABLE id=3D=
INCREDIMAINTABLE cellSpacing=3D0 cellPadding=3D2 width=3D"95%" border=3D0=
>
<TBODY>

<TR>

<TD id=3DINCREDITEXTREGION style=3D"FONT-FAMILY: Comic Sans MS; FONT-SIZE=
: 10pt; PADDING-LEFT: 7px; PADDING-RIGHT: 7px"=20
    width=3D"100%">
      <DIV>I want to know the scenario when the UA should send BYE or=20
      CANCEL.</DIV>
      <DIV>From RFC2543,CANCEL is only used to terminate the pending=20
      request.</DIV>
      <DIV>My question is : whether BYE&nbsp;request also can terminate t=
he=20
      pending request or not?</DIV>
      <DIV>Best regards!!</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>&nbsp;</DIV>
      <DIV>Guy</DIV>
      <DIV>Email:&nbsp; <A=20
      href=3D"mailto:&nbsp;ligang@sict.ac.cn">ligang@sict.ac.cn</A></DIV>
      <DIV>&nbsp;</DIV></TD></TR>
<TR>
<TD id=3DINCREDIFOOTER width=3D"100%">
<TABLE cellSpacing=3D0 cellPadding=3D0 width=3D"100%">
<TBODY>
<TR>
<TD width=3D"100%"></TD>
<TD id=3DINCREDISOUND vAlign=3Dbottom align=3Dmiddle></TD>
<TD id=3DINCREDIANIM vAlign=3Dbottom align=3Dmiddle></TD></TR></TBODY></T=
ABLE></TD></TR></TBODY></TABLE><SPAN=20
id=3DIncrediStamp><SPAN dir=3Dltr><FONT face=3D"Arial, Helvetica, sans-se=
rif"=20
size=3D2>____________________________________________________<BR><FONT=20
face=3D"Comic Sans MS" size=3D2><A=20
href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;lang=3D9"><I=
MG=20
align=3Dbaseline alt=3D"" border=3D0 hspace=3D0=20
src=3D"cid:9C396D79-4828-4D43-B88D-024A313BF700"></A>&nbsp; <I>IncrediMai=
l</I> -=20
<B>Email has finally evolved</B> - </FONT><A=20
href=3D"http://www.incredimail.com/redir.asp?ad_id=3D309&amp;lang=3D9"><F=
ONT=20
face=3D"Times New Roman" size=3D3><B><U>Click=20
Here</U></B></FONT></A></SPAN></SPAN></FONT></BODY></html>
--------------Boundary-00=_4DOUCJD0000000000000--

--------------Boundary-00=_4DOUH890000000000000
Content-Type: image/gif
Content-Transfer-Encoding: base64
Content-ID: <9C396D79-4828-4D43-B88D-024A313BF700>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

R0lGODlhFAAPALMIAP9gAM9gAM8vAM9gL/+QL5AvAGAvAP9gL////wAAAAAAAAAAAAAAAAAAAAAA
AAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQJFAAIACwAAAAAFAAPAAAEVRDJSaudJuudrxlEKI6B
URlCUYyjKpgYAKSgOBSCDEuGDKgrAtC3Q/R+hkPJEDgYCjpKr5A8WK9OaPFZwHoPqm3366VKyeRt
E30tVVRscMHDqV/u+AgAIfkEBWQACAAsAAAAABQADwAABBIQyUmrvTjrzbv/YCiOZGmeaAQAIfkE
CRQACAAsAgABABAADQAABEoQIUOrpXIOwrsPxiQUheeRAgUA49YNhbCqK1kS9grQhXGAhsDBUJgZ
AL2Dcqkk7ogFpvRAokSn0p4PO6UIuUsQggSmFjKXdAgRAQAh+QQFCgAIACwAAAAAFAAPAAAEEhDJ
Sau9OOvNu/9gKI5kaZ5oBAAh+QQJFAAIACwCAAEAEAANAAAEShAhQ6ulcg7Cuw/GJBSF55ECBQDj
1g2FsKorWRL2CtCFcYCGwMFQmBkAvYNyqSTuiAWm9ECiRKfSng87pQi5SxCCBKYWMpd0CBEBACH5
BAVkAAgALAAAAAAUAA8AAAQSEMlJq7046827/2AojmRpnmgEADs=

--------------Boundary-00=_4DOUH890000000000000
Content-Type: Image/jpeg
Content-ID: <BC9950CD-011B-49F3-93FB-F4268D3048D5>
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA
EAMCAwYAAAHbAAAC1gAABZX/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX
Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa
JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAGUAcwMBIgACEQEDEQH/
xACAAAEBAQEAAAAAAAAAAAAAAAAAAQIGAQEBAAAAAAAAAAAAAAAAAAAAARABAAICAwEAAgMAAAAA
AAAAAQARIQIxQRIiQDIQMFARAAICAgIBBAIDAQEAAAAAAAERACExQVFhcYGRobECEsHhMtHxEgEA
AAAAAAAAAAAAAAAAAABQ/9oADAMBAAIRAxEAAADtRZYE1ASghQFgUZoCkKSwLmhcllAEqkSkqFAl
hUomoAS3IoJqFlDNpFEAQFE1AIVYAWIVKAJRNZpYCwVmmshKACA0CBAUCBYGwf/aAAgBAgABBQD8
B/yP/9oACAEDAAEFAPz6/or8H//aAAgBAQABBQC2+ZeHjbD+saX6hwXeDW1Rg4xLLTa+m7ZiIEsI
1MTiHP1dYpvFADiFM1/X6nq9byuwdPPz5oFofWlEMQ9ULKrWq2ppG9Y2J6INQma9lVTRdlUKgHzX
XSEECw1SYu5WsGoJPkisZYpx31GvXZQ/JM3VwShzVTsp1EZbBI8LcaUSih86+s2Zl4Wp6+lAZnVs
Dkjdku5m+lJTdXDG2SHM9M2wKX1YxsaZTTwmoVrYnqsMrM652yjs01K0mtbGAz6Y5dpfqNz06qpq
5QNjiIjiZtbhtceNuf0jyeqGgu6rXMvI4omPWbPMYzEfMI+axHnFvOP4/9oACAECAgY/AGP/2gAI
AQMCBj8AY//aAAgBAQEGPwB72Yucb1BfIhFEaeZ+xRXFQELN+HEUQdjU0Xn4g9gRCQcpw1yajGYs
P/kFvUzvjUBWrIMFHI2OJQNEAjiEEFdTmfG/MTHq5RFOnpTV3kzCBx7x4YOD1AV5uYJvnqMA0hep
jfwpYCwC4Bx3q55zeZRBCw9TkoIuHw78RdczSNH2mgqcLpRC+RASAkA3B13mcYd5mR84c/yOx4lW
tRAZ6mGDhiP9WgXVyhWA+xDgMOWGMsTg/wBTz8SjjXrP8hHIlX1MZ6mDzgc/cIV/iyN1GBR0MQMK
jnEzvvMz8mUkErKlfqU63iV+IKNH7mNZBLFQEpEDeDOV32IVn8WR4caoywqI2p695mbZzNUQIcKf
k0bo+0NpCqn7CiQiNGXkdQen1DpjGeZ7WNw3pK+I93maCPc16+Zkf6XxMCsFwAkaiIB57vc/IAhZ
/HqZBBbB0ZokAEOGxsYqBgPp8agQBu4VSMJdqx6SwDsGBrTmAR93uZGX6KePowEADAIjoX8gw459
CICaW/MLGvodQfkDW71zBxRHtB3j3jC4PMIYoAgKNfPMCQNN7jCzvlzXPopzhQvNZY3CRya9ZrEF
fRE0iCB5mscZuVYfKmAi94uE3Q8qfytQ7xD0svmFcmaxNPI8iMjh3pmF2HbzqeUi+YkiD/MrOl5L
mbwPuWVfmXpv3hDH8qAjPpiZHXkRnSd6ZhB53mejzKV6US0K9TCCLyCeIhtETX5MsHBGJkD/ANiF
kMCE2qGoCdZ8Q8AMGpYFqEhdhRIYH3CF3d1M/Mexma+4CwdQ2Ddcx0exAlmj04QUQd8QWLB/iB5G
xmEg5TENVZqPYzFV8eHAy9T/AEc8a4n3Ov6g/VwvE6lpQ4VNysXzhS8esOO8w/rlF/rypjV3B5H1
Knr8T//Z

--------------Boundary-00=_4DOUH890000000000000--


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



From daemon@ns.ietf.org  Tue May 28 23:05:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08089
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 23:05:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA10257
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 23:05:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06539;
	Tue, 28 May 2002 22:20:34 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06511
	for <sip@ns.ietf.org>; Tue, 28 May 2002 22:20:31 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06874
	for <sip@ietf.org>; Tue, 28 May 2002 22:20:07 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4T2JpIZ011645
	for <sip@ietf.org>; Tue, 28 May 2002 19:19:51 -0700 (PDT)
Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AAF01003;
	Tue, 28 May 2002 19:19:50 -0700 (PDT)
Date: Tue, 28 May 2002 19:16:11 -0700 (Pacific Daylight Time)
From: Rohan Mahy <rohan@cisco.com>
To: sip@ietf.org
Message-ID: <Pine.WNT.4.44.0205281912170.-474143@chorizo.rapidconvergence.com>
X-X-Sender: rmahy@imop.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Sip] P- headers vs. requirements in sip change process
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

>From tsvarea-sipchange the requirements for P- headers are:

   1. Expert Review
   2. No option tags, response codes, or methods
   3. No overlap with planned/chartered extensions
   4. Purely informational in nature
   5. Does not undermine security
   6. Clearly documented in RFC
   7. Appropriate applicability statement

I've taken a stab at documenting compliance with these requirements.
I've also included an evaluation of call-auth as a comparison.

Please note that in future proposed P- headers should go through SIPPING.

draft-ietf-sip-call-auth

1. Expert Review
   Via the SIP working group as WG document
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Minor caveats, well documented
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Yes, very narrow in scope

draft-ietf-sip-asserted-identity

1. Expert Review
   Via WG as WG document
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   Some overlap with future crytographic identity work,
   scope of overlap intentionally narrow
4. Purely informational in nature
   OK
5. Does not undermine security
   Minor caveats, usage well documented
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Yes, very narrow scope

draft-garcia-sip-visited-network-id

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Negligible impact, well documented
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Needs to provide more general usage guidance

draft-garcia-sip-called-party-id

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   some overlap with request-history work, very narrow in scope
4. Purely informational in nature
   OK
5. Does not undermine security
   Some privacy concerns
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Needs to provide more general usage guidance,
   Should mention the partial overlap with request history

draft-garcia-sip-associated-uri

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Some privacy concerns, can be addressed
   with standard mechanisms
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Needs to provide more general usage guidance

draft-henrikson-sip-charging-information

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   ?
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   Some good general guidance given, need to explain when NOT to use

draft-henrikson-sip-orig-dialog-id

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   significant overlap with SIP state, and cookies
   (chartered work)
4. Purely informational in nature
   Unclear. Appears to change algorithm used for SIP routing
5. Does not undermine security
   Unclear
6. Clearly documented in RFC
   Not yet
7. Appropriate applicability statement
   Needs to provide more general usage guidance

draft-mills-sip-access-network-info

1. Expert Review
   some review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   Some privacy concerns; generally well addressed in security section
6. Clearly documented in RFC
   OK
7. Appropriate applicability statement
   No applicability statement present

draft-willis-sip-svcrtdisco

1. Expert Review
   good level of review from SIP WG
2. No option tags, response codes, or methods
   OK
3. No overlap with planned/chartered extensions
   No overlap
4. Purely informational in nature
   OK
5. Does not undermine security
   minor caveats addressed in security considerations
6. Clearly documented in RFC
   Yes
7. Appropriate applicability statement
   Some general guidance given, need to explain when NOT to use

In addition there is an informational event package proposed...

draft-beckmann-sip-reg-event

1. Expert Review
   some review in SIP, really needs review in SIMPLE
2. No template-packages
   OK
3. No overlap with planned/chartered extensions
   This appears to be a generically useful event package
   which should be addressed as a charter item in SIPPING
   Jonathan Rosenberg proposed such a document
4. Does not contradict normative behavior
   OK
5. Does not undermine security
   Mechanism introduces no new security concerns
6. Clearly documented in RFC
   Needs more detail - underspecified
7. Appropriate applicability statement
   No applicability statement present
   Probably not needed if this becomes a general purpose mechanism






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



From daemon@ns.ietf.org  Tue May 28 23:14:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08186
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 23:14:55 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA10645
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 23:15:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07975;
	Tue, 28 May 2002 22:34:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA07905
	for <sip@ns.ietf.org>; Tue, 28 May 2002 22:34:14 -0400 (EDT)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07363;
	Tue, 28 May 2002 22:33:48 -0400 (EDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 19:33:41 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 May 2002 19:33:40 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Tue, 28 May 2002 19:33:41 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 28 May 2002 19:33:40 -0700
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0);
	 Tue, 28 May 2002 19:33:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
Date: Tue, 28 May 2002 19:33:40 -0700
Message-ID: <F66A04C29AD9034A8205949AD0C9010401C0E540@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed Standard
thread-index: AcIGnQfWL8cYWdzsTB+aVSsgguNWFwAGpZsQ
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Dean Willis" <dean.willis@softarmor.com>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: <iesg@ietf.org>, <sip@ietf.org>
X-OriginalArrivalTime: 29 May 2002 02:33:40.0581 (UTC) FILETIME=[3E6C8150:01C206B9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA07908
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

> > Could it be that this "sip proxy controlling the firewall" is
> > part of the problem rather than part of the solution? It is
> > certainly not part of the IP architecture...
> 
> Yes, I'm sure that dealing with reality is out-of-scope for our
> architecture. That's why we've been so successful at curtailing the
> spread of NAT and firewall boxes and assuring interoperability when
they
> do spontaneously appear.

OK, so here is a reality check: the specific proposal is for a DHCPv6
option -- that is, DHCP for IPv6. Either IPv6 is actually deployed, in
which case we don't need the NAT, or IPv6 is not deployed, in which case
we don't need the option. As for firewall traversal, I have a very hard
time believing that an enterprise firewall that you randomly discovered
through DHCP will let you send UDP packet through -- that will require
at a minimum some solid exchange of credentials.

> Your argument, while principaled, is consistent with the declaration
> that since cars are approximately two horses wide (see "The Standard
> that Wouldn't Die") we should be able to feed them grain, steer them
> with reins and control their velocity with a buggy whip.

Uh, is this useful?

-- Christian Huitema

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



From daemon@ns.ietf.org  Tue May 28 23:37:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08780
	for <sip-archive@odin.ietf.org>; Tue, 28 May 2002 23:37:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA11845
	for sip-archive@odin.ietf.org; Tue, 28 May 2002 23:38:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09314;
	Tue, 28 May 2002 22:59:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA09283
	for <sip@ns.ietf.org>; Tue, 28 May 2002 22:59:52 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07919
	for <sip@ietf.org>; Tue, 28 May 2002 22:59:27 -0400 (EDT)
Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4T2xKHs003807
	for <sip@ietf.org>; Tue, 28 May 2002 19:59:20 -0700 (PDT)
Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint Messaging Server MOS 3.1.0.54-GA)
	with ESMTP id AAF01278;
	Tue, 28 May 2002 19:59:19 -0700 (PDT)
Date: Tue, 28 May 2002 19:55:40 -0700 (Pacific Daylight Time)
From: Rohan Mahy <rohan@cisco.com>
To: sip@ietf.org
Message-ID: <Pine.WNT.4.44.0205281953080.-618899@chorizo.rapidconvergence.com>
X-X-Sender: rmahy@imop.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [Sip] Generic Registration Package
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

I posted a question asking if we want to adopt a generic event package for
the status of registrations on the SIPPING list.  Without requirements,
that is where all new work should go.

thanks,
-rohan



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



From daemon@ns.ietf.org  Wed May 29 02:15:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20151
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 02:15:35 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA02426
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 02:16:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26578;
	Wed, 29 May 2002 01:58:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA26547
	for <sip@ns.ietf.org>; Wed, 29 May 2002 01:57:57 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10852
	for <sip@ietf.org>; Wed, 29 May 2002 01:57:30 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4T5vgmG022263;
	Wed, 29 May 2002 07:57:42 +0200 (MEST)
Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4T5vfgu007757;
	Wed, 29 May 2002 08:57:41 +0300 (EET DST)
Message-ID: <3CF46DD5.66298EA1@lmf.ericsson.se>
Date: Wed, 29 May 2002 08:57:41 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@lmf.ericsson.se>
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'sip'" <sip@ietf.org>, "'Jonathan Rosemberg'" <jdrosen@dynamicsoft.com>,
        "'Henning Schulzrinne'" <hgs@cs.columbia.edu>
Subject: Re: [Sip] New version of the SIP over SCTP draft
References: <00ad01c2067d$1ccb2830$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi Dean,

Yes, I already warned the editor about this. The new version should be
02. In fact, the only thing I forgot was to change the name of the file,
since the draft itself says 02 above the title.

Thanks,

Gonzalo

Dean Willis wrote:
> 
> Warning! There appears to be a revision numbering issue.
> 
> I have a file by the same name on the supplemental site which appears to
> have been published last November.
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-sctp-01.txt
> 
> Which replaced
> 
> http://www.softarmor.com/sipwg/drafts/morgue/draft-ietf-sip-sctp-00.txt
> published last August.
> 
> Perhaps the latest rev should be -02?
> 
> --
> Dean
> 
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On
> > Behalf Of Gonzalo Camarillo
> > Sent: Tuesday, May 28, 2002 5:18 AM
> > To: sip
> > Cc: Jonathan Rosemberg; Henning Schulzrinne
> > Subject: [Sip] New version of the SIP over SCTP draft
> >
> >
> > Hello,
> >
> > I have just submitted a new version of the SIP over SCTP draft.
> >
> http://www.cs.columbia.edu/~gonzalo/draft-ietf-sip-sctp-01.txt
> 
> I have not changed anything. I have only updated the references (now
> they are divided into normative and informative ones).
> 
> I am re-submitting this draft because its LC is scheduled for July, and
> version 00 expires in May 2002 (i.e., right now).
> 
> Regards,
> 
> Gonzalo
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
> Finland                   http://www.hut.fi/~gonzalo
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip Use
> sipping@ietf.org for new developments on the application of sip

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.hut.fi/~gonzalo

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



From daemon@optimus.ietf.org  Wed May 29 07:08:22 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10282
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 07:08:21 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA01221
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:08:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00189;
	Wed, 29 May 2002 06:46:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00155
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 06:46:00 -0400 (EDT)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10075
	for <sip@ietf.org>; Wed, 29 May 2002 06:45:35 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4TAiec25873;
	Wed, 29 May 2002 06:44:41 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25Z48LY>; Wed, 29 May 2002 05:44:35 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870375@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Juha Heinanen'" <jh@lohi.eng.song.fi>,
        Cullen Jennings
	 <fluffy@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00
Date: Wed, 29 May 2002 05:44:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


I don't think anything that is expressed in this draft is incompatible with
what you're attempting to accomplish with the normative statements below -
except in so far as you levy restrictions that are not meaningful for all
networks.

"Hint", for whatever reason, is the term that has stuck throughout this
discussion. There are meaningful cases in which a network would elect to use
some identity other than that hinted by the user, so I don't feel this term
is entirely inappropriate.

There is a concept, though one that is not discussed extensively in the
draft, that a user authenticates themselves in some fashion to the network.
The Spec(T) example in the draft suggests SIP Digest authentication, if I
recall. The P-Asserted-Identity could be populated based on an identity
expressed in that authentication process, rather than a From header, in the
absence of a hint (although admittedly in some networks the authentication
will not supply a usable identity as such). This applies equally to cases in
which the user has supplied an anonymous From header. This would seem to
provide a credible alternative to the MUST that you suggest below, one that
I see no reason to rule out.

The short-term identity work puts the network, not the user, firmly in the
driver's seat. There are other forms of identity (like the contents of the
>From header field) that are more directly under the user's control. You are
welcome to apply whatever policies you like for proxy servers in your own
network, including the ones you enumerate below. I don't think this requires
any support in the protocol, though. We mention, but do not mandate, that a
proxy server can reject requests that have an inappropriate hint. I'm not
sure I see any value in strengthening this.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@lohi.eng.song.fi]
> Sent: Tuesday, May 28, 2002 12:23 AM
> To: Cullen Jennings
> Cc: sip@ietf.org
> Subject: [Sip] draft-ietf-sip-asserted-identity-00
> 
> 
> once again:
> 
> the term "hint" is not a good one.  if user adds the a-i, then the
> network MUST respect it or reject the request.  the network MUST not
> override the a-i and pick one of the identities on its own.  for
> example, the user may have misspelled the its uri in the a-i.
> 
> also, the text should say that in case from is anonymous the user MUST
> insert the a-i header if it has multiple identities, because otherwise
> the network cannot know which identity the user wants to use.
> 
> finally, for backwards compatibility, if from is not anonymous and the
> user has multiple identities, then from uri can serve as the 
> purpose of
> a-i.
> 
> -- 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 daemon@optimus.ietf.org  Wed May 29 07:47:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11708
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 07:47:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA03800
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:47:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02949;
	Wed, 29 May 2002 07:34:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02916
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 07:34:05 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11209;
	Wed, 29 May 2002 07:33:38 -0400 (EDT)
Message-Id: <200205291133.HAA11209@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 29 May 2002 07:33:37 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-sctp-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: SCTP as a Transport for SIP
	Author(s)	: J. Rosenberg, H. Schulzrinne, G. Camarillo
	Filename	: draft-ietf-sip-sctp-02.txt
	Pages		: 11
	Date		: 28-May-02
	
This document specifies a mechanism for usage of SCTP (the Stream
Control Transmission Protocol) as the transport between SIP entities.
SCTP is a new protocol which provides several features that may prove
beneficial for transport between SIP entities which exchange a large
amount of messages, including gateways and proxies. As SIP is
transport independent, support of SCTP is a relatively
straightforward process, nearly identical to support for TCP.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May 29 07:47:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11730
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 07:47:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA03851
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:48:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02677;
	Wed, 29 May 2002 07:33:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02647
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 07:32:58 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10977;
	Wed, 29 May 2002 07:32:31 -0400 (EDT)
Message-Id: <200205291132.HAA10977@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 29 May 2002 07:32:30 -0400
Subject: [Sip] I-D ACTION:draft-mills-sip-access-network-info-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: The SIP Access Network Info header
	Author(s)	: D. Mills
	Filename	: draft-mills-sip-access-network-info-02.txt
	Pages		: 8
	Date		: 28-May-02
	
This mechanism is useful in SIP networks that provide layer 2/layer 
3 connectivity through different access technologies. SIP User 
Agents 
This document defines the private SIP extension header P-Access-
Network-Info. may use this header to relay information about the 
access technology to serving proxies in their home network. The 
serving proxy may then use this information to optimize services for 
the UA. For example, a 3GPP terminal uses this header to pass 
information about the access network such as radio access technology 
and cell ID to its home service.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-mills-sip-access-network-info-02.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May 29 07:50:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11938
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 07:50:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA03964
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:51:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03109;
	Wed, 29 May 2002 07:34:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02993
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 07:34:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11246;
	Wed, 29 May 2002 07:33:49 -0400 (EDT)
Message-Id: <200205291133.HAA11246@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 29 May 2002 07:33:49 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-privacy-general-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: A Privacy Mechanism for the Session Initiation 
                          Protocol (SIP)
	Author(s)	: J. Peterson
	Filename	: draft-ietf-sip-privacy-general-00.txt
	Pages		: 28
	Date		: 28-May-02
	
This document defines new mechanisms for the Session Initiation
Protocol (SIP) in support of privacy.  Specifically, guidelines are
provided for the creation of messages that do not divulge personal
identity information.  A new 'privacy service' logical role for
intermediaries is defined to answer some privacy requirements that
user agents cannot satisfy themselves.  Finally, means are presented
by which a user can request particular functions from a privacy
service.

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

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

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

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


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

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

--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:	<20020528133320.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-privacy-general-00.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May 29 07:53:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12079
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 07:53:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA04088
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:53:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02494;
	Wed, 29 May 2002 07:31:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02462
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 07:31:38 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10731;
	Wed, 29 May 2002 07:31:10 -0400 (EDT)
Message-Id: <200205291131.HAA10731@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 29 May 2002 07:31:09 -0400
Subject: [Sip] I-D ACTION:draft-rosenberg-sip-reg-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Session Initiation Protocol (SIP) Event Package for 
                          Registrations
	Author(s)	: J. Rosenberg
	Filename	: draft-rosenberg-sip-reg-00.txt
	Pages		: 24
	Date		: 28-May-02
	
This document defines a Session Initiation Protocol (SIP) event
package for registrations. Through its REGISTER method, SIP allows a
user agent to create, modify, and delete registrations. Registrations
can also be altered by administrators in order to enforce policy.
These registrations therefore represent a piece of state in the
network that can change dynamically. There are many cases where a
user agent would like to be notified of changes in this state. This
event package defines a mechanism by which those user agents can
request and obtain such notifications

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

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

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

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


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

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

--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:	<20020528130450.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rosenberg-sip-reg-00.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May 29 07:53:04 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12093
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 07:53:03 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA04102
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:53:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02989;
	Wed, 29 May 2002 07:34:16 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02951
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 07:34:11 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11227;
	Wed, 29 May 2002 07:33:43 -0400 (EDT)
Message-Id: <200205291133.HAA11227@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 29 May 2002 07:33:42 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-asserted-identity-00.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: Extensions to the Session Initiation Protocol (SIP) 
                          for Asserted Identity within Trusted Networks
	Author(s)	: C. Jennings, J. Peterson, M. Watson
	Filename	: draft-ietf-sip-asserted-identity-00.txt
	Pages		: 17
	Date		: 28-May-02
	
This document describes private extensions to SIP that enable a
network of trusted SIP servers to assert the identity of end users or
end systems, and the application of existing privacy mechanisms to
the identity problem.  The use of these extensions is only applicable
inside an administrative domain with previously agreed-upon policies
for generation, transport and usage of such information.  This
document does NOT offer a general privacy or identity model suitable
for inter-domain use, or use in the Internet at large.

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

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

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

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


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

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

--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:	<20020528133256.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-asserted-identity-00.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May 29 07:55:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12187
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 07:55:51 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA04310
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 07:56:16 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02546;
	Wed, 29 May 2002 07:31:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02516
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 07:31:55 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10776;
	Wed, 29 May 2002 07:31:22 -0400 (EDT)
Message-Id: <200205291131.HAA10776@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Wed, 29 May 2002 07:31:21 -0400
Subject: [Sip] I-D ACTION:draft-camarillo-sip-compression-01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Compressing the Session Initiation Protocol
	Author(s)	: G. Camarillo
	Filename	: draft-camarillo-sip-compression-01.txt
	Pages		: 11
	Date		: 28-May-02
	
This document describes a mechanism to signal that compression is
desired for one or more SIP messages. It also states when it is
appropriate to send compressed SIP messages to a SIP entity.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-camarillo-sip-compression-01.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-camarillo-sip-compression-01.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:	<20020528130511.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-camarillo-sip-compression-01.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Wed May 29 08:22:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13420
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 08:22:19 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA06505
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 08:22:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04522;
	Wed, 29 May 2002 07:57:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00209
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 06:47:25 -0400 (EDT)
Received: from hotmail.com (f314.law10.hotmail.com [64.4.14.189])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10078
	for <sip@ietf.org>; Wed, 29 May 2002 06:47:00 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 29 May 2002 03:46:54 -0700
Received: from 192.35.17.22 by lw10fd.law10.hotmail.msn.com with HTTP;
	Wed, 29 May 2002 10:46:54 GMT
X-Originating-IP: [192.35.17.22]
From: "Salva Rey" <salreyca@hotmail.com>
To: sip@ietf.org
Date: Wed, 29 May 2002 10:46:54 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F314q6bsVBM3bpWCeRL0000d81b@hotmail.com>
X-OriginalArrivalTime: 29 May 2002 10:46:54.0336 (UTC) FILETIME=[25AD2800:01C206FE]
Subject: [Sip] transaction layer
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


Sorry, I posted a very similar question before, the change and addition are 
in between quote marks.

if sending a response on a server transaction a transport error occurs,
should the "transaction layer" try on all the destinations resolved by
draft-ietf-sip-srv-06.txt (used as reference [4] in draft rfc-2534bis-09),
before informing the transaction user of the error, "and transitioning to 
the terminated state"?

thanks a lot,
Salva Rey


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx



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



From daemon@optimus.ietf.org  Wed May 29 08:27:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13541
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 08:27:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA07081
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 08:27:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA04492;
	Wed, 29 May 2002 07:57:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00007
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 06:41:34 -0400 (EDT)
Received: from hotmail.com (f198.law10.hotmail.com [64.4.15.198])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10006
	for <sip@ietf.org>; Wed, 29 May 2002 06:41:09 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 29 May 2002 03:41:03 -0700
Received: from 192.35.17.22 by lw10fd.law10.hotmail.msn.com with HTTP;
	Wed, 29 May 2002 10:41:03 GMT
X-Originating-IP: [192.35.17.22]
From: "Salva Rey" <salreyca@hotmail.com>
To: sip@ietf.org
Date: Wed, 29 May 2002 10:41:03 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F198pROvdLnAc7JXoDR0000ea58@hotmail.com>
X-OriginalArrivalTime: 29 May 2002 10:41:03.0892 (UTC) FILETIME=[54CBA540:01C206FD]
Subject: [Sip] Transport layer
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Hi,

if sending a response on a server transaction a transport error occurs, 
should the transport layer try on all the destinations resolved by 
draft-ietf-sip-srv-06.txt (used as reference [4] in draft rfc-2534bis-09), 
before informing the transaction user of the error?

thanks a lot,
Salva Rey



_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.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 daemon@optimus.ietf.org  Wed May 29 09:08:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15248
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 09:08:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA11894
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:08:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09825;
	Wed, 29 May 2002 08:49:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09713
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 08:49:20 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14362
	for <sip@ietf.org>; Wed, 29 May 2002 08:48:53 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmemG021093;
	Wed, 29 May 2002 14:48:40 +0200 (MEST)
Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmcIJ006794;
	Wed, 29 May 2002 15:48:38 +0300 (EET DST)
Message-ID: <3CF4CD58.6A0BE283@ericsson.com>
Date: Wed, 29 May 2002 15:45:12 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Bob Penfield <bpenfield@acmepacket.com>
CC: Tan Ya-Ching ICM N PG U ID A 1 <Ya-Ching.Tan@icn.siemens.de>, sip@ietf.org
Subject: Re: [Sip] Comments on draft-garcia-sip-called-party-id-01
References: <5B4D0C5BA65ECA46969C1419122317E6E74DDC@mchh161e> <3CF1FC20.3CFDAEE6@ericsson.com> <002001c20671$db2b14e0$2300000a@acmepacket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Bob:

Thanks for your comments. Answers inline.

/Miguel

Bob Penfield wrote:
> 
> A couple follow-ups and one new comment below
> 
[snip]
> 
> Does the fact that one would want to use P-Called-Party-ID when they cannot
> (or will not) rely on the To field, need be included in the applicability
> statement?

IMHO any decent implementation should not rely on the To header for any other
thing that maintaining the dialogs (and for that you need only the tag).
This should be evident for the SIP ilustrated reader. Therefore, I don't 
think it is necessary to add anything else in the applicability statement.

> 
> ><snip>
> > > | >   o The term "standalone method" is not defined in SIP RFC.
> > > |
> > > | <miguel>
> > > | I'll fix it somehow, but I think that the term standalone,
> > > | although not define in RFC 3261, is understandable by the
> > > | reader familiar with SIP.
> > > | </miguel>
> > >
> > > RFC 3261 even defines terms such as "Message", "Parallel Search". One
> simply
> > > can't start using a new term like "standalone request" or "standalone
> > > transaction request" and assume that it is 'understandable by the reader
> > > familiar with SIP'.
> > >
> >
> > <miguel>Yes, I understand your comment. I will do my best to make it
> > clear what it means in the next version.
> > </miguel>
> 
> I think what you are trying to say is that the P-Called-Party-ID can be
> inserted in any request that initiates a dialog, or any request that is
> completely outside of a dialog. These should be the only requests that would
> have been issued with an AOR type Request-URI that a proxy would replace.
> All other requests (those within an existing dialog) would have a
> Request-URI equal to a URI that the UA learned from a Contact header in the
> request/response that created the dialog. Is this correct?

Precisely.

 
> New issue:
> 
> In the header field table in Section 5, shouldn't the header be optional for
> a SUBSCRIBE and not allowed for a NOTIFY? SUBSCRIBE initiates a dialog, and
> NOTIFY should use the value from the Contact of the SUBSCRIBE for the R-URI
> (thus R-URI would not be changed by a proxy).

Definitely. Thanks for catching the bug.

> 
> cheers,
> (-:bob

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002


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



From daemon@optimus.ietf.org  Wed May 29 09:08:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15265
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 09:08:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA11909
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:08:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09836;
	Wed, 29 May 2002 08:49:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09719
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 08:49:21 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14365
	for <sip@ietf.org>; Wed, 29 May 2002 08:48:53 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmW6n023273;
	Wed, 29 May 2002 14:48:32 +0200 (MEST)
Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmTIJ006770;
	Wed, 29 May 2002 15:48:29 +0300 (EET DST)
Message-ID: <3CF4CA18.C875EE15@ericsson.com>
Date: Wed, 29 May 2002 15:31:20 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <3CF3596B.13D72E7@ericsson.com> <3CF3B0B1.F176F2F4@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> "Miguel A. Garcia" wrote:
> >
> 
> > > On an unrelated note, I must admit being baffled about why this is
> > > useful in a subscribe response. It seems like the associated URI are
> > > closely related to registrations, not subscriptions.
> >
> > And in fact, the only usage in 3GPP is in registrations. But I got
> > some comments that this may be useful in subscriptions as well. If
> > nobody
> > shouts, I will remove the usage of the header in subscriptions and
> > restrict
> > the scope to REGISTER only.
> 
> Yes, please. I think we should strive to limit scope for P-headers, not
> the other way around. This is especially true when the motivating need
> is not even clear.

Miguel-> Fine. I fixed that.

> > > 1. the syntax does not permit an empty value for the P-Associated-URI.
> > > What happens if there are no associated URI? If you simply omit the
> > > header altogetrher, how does the UA distinguish the case where the
> > > registrar doesn't support the extension, as opposed to the registrar
> > has
> > > no associated URIs?
> >
> > Do we need to make a distinction between both cases? Either case, the
> > user knows that no other identities are associated by the registrar,
> > and therefore, explicit actions (e.g., REGISTER) has to be taken by
> > the UAC.
> 
> I thought you indicated below that this extension did not imply the
> registration of the associated identities...
> 
> That aside, it does make a difference. The UA needs to know whether it
> can put any identity it likes in the From field (since the network is
> not trying to impose restrictions on the set), or whether it can't put
> any identity except the one it registered (since the network is imposing
> restrictions, and there is just one valid identity).

Miguel-> Fine. I added some text explaining this situation.

> > > 2. Is there an implicit assumption that the registrar will register
> > the
> > > associated URI? I believe this is true in the 3gpp case. A UA probably
> > > needs to know whether they have been registered or not. I would not
> > want
> > > to put a URI into a Reply-To header unless I knew it was a valid URI
> > for
> > > receiving incoming calls....
> >
> > No, this is not the case. The "reg" event will provide such information.
> > But the semantics of this header is just to provide a set of IDs that
> > the
> > user has associated to the address-of-record. They may or may not be
> > registered,
> > the user will know this information by other means (subscription to the
> > registration event package). The user knows that he can initiate
> > registration
> > of any of the returned IDs, or it can populate the From with any of
> > those
> > IDs as well. That's it.
> 
> Presumably the UA will need to make sure that they are registered; you
> should probably note in the draft that there is no assumption that the
> associated URI are registered, and that if the UA wants that, it should
> check and perform the registrations if needed.

Miguel-> Done. I some text referencing the registration event package,
as the mechanism to guess whether the associated URIs are registered or not.
 
> > > > 5.3 Procedures at the proxy
> > > >
> > > >    This memo does not define any procedures at the proxy.
> > > >
> > >
> > > Well, presumably some proxy will enforce the list of associated-URI,
> > and
> > > reject requests that have a value in the From field not amongst the
> > > allowed set? Is there a new response code for that?
> >
> > Yes, the proxy will send a 403 Forbidden. However, I don't think this is
> >
> > part of the scope of this I-D. I understand that the title "Procedures
> > at
> > the proxy" are procedures related to the extension (the header in this
> > case).
> > The idea in this I-D is to convey to the UA the list of URIs that he can
> > use
> > in subsequent requests, not how to police them. Therefore, there are not
> > procedures at the proxy related to the P-Associated-URI header.
> 
> Well, its all intertwined. The associated-URI list is the only way a UA
> has to retry if it should get this error, since it conveys the allowed
> URI in the first place. Actually, 403 is really NOT the right response.
> If it gets this, how does the UA recover? It needs to know that the
> problem was a disallowed From value, and it needs to know which ones are
> OK. I would argue that the way to deal with this is a new response code
> that would contain in it the Associated-URI header indicating which ones
> are allowed.

There are two issues to solve here, namely:
1) Does the UAC need to know there was something wrong with one of the
   headers? I would say, yes. And I agree that the proxy should return
   the list of allowed IDs in the form of a P-Associated-URI.
2) Is 403 the best response code? I don't see why 403 is not a right
   response code *if we add the P-Associated-URI* to the response in
   the 403. Once must notice also that P- headers can't add a new 
   response code.

So my proposal: the policy enforcement proxy returns a 403 response
in case the URI in the From header or any other SIP header value that 
provides information of the identity of the calling party is not 
populated with any of the allowable URIs. The proxy adds a 
P-Associated-URI header with the complete list of allowable URIs to
the user. Is this correct?

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002



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



From daemon@optimus.ietf.org  Wed May 29 09:08:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15280
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 09:08:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA11923
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:08:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09810;
	Wed, 29 May 2002 08:49:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09706
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 08:49:20 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14364
	for <sip@ietf.org>; Wed, 29 May 2002 08:48:53 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmNmG020941;
	Wed, 29 May 2002 14:48:23 +0200 (MEST)
Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmJIJ006757;
	Wed, 29 May 2002 15:48:20 +0300 (EET DST)
Message-ID: <3CF4B20D.5180A4F7@ericsson.com>
Date: Wed, 29 May 2002 13:48:45 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: Michael Thomas <mat@cisco.com>, Dean Willis <dean.willis@softarmor.com>,
        sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com,
        jo@ipdialog.com
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <15603.34487.286237.10847@thomasm-u1.cisco.com> <3CF3AEF9.EF57314C@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Michael Thomas wrote:
> >
> > So, I have a really dumb question. Why don't you
> > limit the number of assertable identities by
> > cryptographic means? That is, if I can't prove
> > that I own an identity binding, it gets dumped
> > on the floor?
> 
> Sure; I think the issue (Miguel can correct me if I'm wrong), is that
> the UA needs to be configured with the set of identities it can claim in
> the first place. The same credentials would allow the user to assert any
> one of those, but the phone needs to know which it should present to the
> user to use.

Jonathan, I must correct you. This is the story in 3GPP: there may be cases
where the user has one identity configured in a special SIM card called the
IMS SIM (ISIM). The network may have allocated other identities to the user, 
and those IDs arepreconfigured in the network, but not in the terminal nor 
in the ISIM. The user will register with the ID configured in the ISIM and 
will get back the others allocated to him.

There are other cases where the user may not even have an ISIM. It has only
a UMTS SIM, USIM (let's say, the old card). In this case, there is nothing
related to SIP configured in his SIM card, becuase that card was developped 
before SIP was introduced in 3GPP. The terminal will derive certain SIP 
identites from the USIM, it will register to his home network, and get back
"the real" SIP identities.

Summarizing, there are cases where the user does not even know who he is.
So no, we can't take the assumption that the UA is aware of all the 
identities allocated to him.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002



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



From daemon@optimus.ietf.org  Wed May 29 09:14:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15600
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 09:14:26 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA12476
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:14:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09788;
	Wed, 29 May 2002 08:49:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09712
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 08:49:20 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14363
	for <sip@ietf.org>; Wed, 29 May 2002 08:48:53 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TCmbmG021052;
	Wed, 29 May 2002 14:48:37 +0200 (MEST)
Received: from ericsson.com (ppp14.lmf.ericsson.se [131.160.102.14])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4TCmXIJ006778;
	Wed, 29 May 2002 15:48:34 +0300 (EET DST)
Message-ID: <3CF4CBEB.42321922@ericsson.com>
Date: Wed, 29 May 2002 15:39:07 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Michael Thomas'" <mat@cisco.com>, sip@ietf.org, rohan@cisco.com,
        brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <00b101c2067d$1e940150$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Dean Willis wrote:
> 
> > Michael Thomas wrote:
> > >
> > > So, I have a really dumb question. Why don't you
> > > limit the number of assertable identities by
> > > cryptographic means? That is, if I can't prove
> > > that I own an identity binding, it gets dumped
> > > on the floor?
> >
> > Sure; I think the issue (Miguel can correct me if I'm wrong),
> > is that the UA needs to be configured with the set of
> > identities it can claim in the first place. The same
> > credentials would allow the user to assert any one of those,
> > but the phone needs to know which it should present to the
> > user to use.
> 
> It goes a little further than this. We're also informing the UA of a
> number of extisting "aliases". The UA can expect to see calls "To:" any
> of these aliases, and needs to delivery them appropriately to the user
> as direct calls rather than as calls targeted originally to some other
> user that have just been forwarded here. This might interact with
> distinctive-ringing features, for example.

I don't know where did you get this information, but as far as I know,
what you are saying is not within the scope of the draft. You are 
assuming an implicit 3rd party registration of all the associated URIs.
And I have just added some text to the draft to clarify that this is 
not the case. The associated URIs, in the general case, are not
implicitly registered. The UAC should use other mechanism, such as
a subscription to its own registration event to guess it.
 
In 3GPP some of the associated-URIs are implicitly registered by the
registrar, but that is not even the general case for the 
P-Associated-URI.

/Miguel

> So there is applicability in both "UA-originated" and UA-terminated"
> scenarios, and there is no requirement that the client be able to
> cryptographically assert the identity associated with an inbound alias.
> 
> --
> Dean

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002



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



From daemon@optimus.ietf.org  Wed May 29 09:31:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16387
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 09:31:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA13580
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 09:32:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12325;
	Wed, 29 May 2002 09:13:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12282
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 09:13:18 -0400 (EDT)
Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15543
	for <sip@ietf.org>; Wed, 29 May 2002 09:12:56 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 29 May 2002 08:11:21 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <7E06D3212981524CA10D2A114937C41484AE25@NREXCH.netrake.net>
Thread-Topic: Comment on draft-willis-sip-scvrtdisco-05
Thread-Index: AcIHElNxu/xsR5PmSB+Vh+XdzsVwrQ==
From: "Rob Phillips" <rob@netrake.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA12283
Subject: [Sip] Comment on draft-willis-sip-scvrtdisco-05
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

In section 5 "Syntax", why is the form for P-Service-Route:

	P-Service-Route = "P-Service-Route" HCOLON 1#( p-sr-value)

instead of what is the defacto common form:

	P-Service-Route = "P-Service-Route" HCOLON p-sr-value *( COMMA p-sr-value )

Additionally, if the first form is used, what is the delimiter between p-sr-value fields?  Can I assume it's WSP?

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074


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



From daemon@optimus.ietf.org  Wed May 29 10:44:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19700
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 10:44:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA18721
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 10:44:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16743;
	Wed, 29 May 2002 10:16:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA16712
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 10:16:04 -0400 (EDT)
Received: from NREXCH.netrake.net (nrexch.Netrake.com [65.119.52.238])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18687
	for <sip@ietf.org>; Wed, 29 May 2002 10:15:40 -0400 (EDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 29 May 2002 09:15:27 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <7E06D3212981524CA10D2A114937C41484AE26@NREXCH.netrake.net>
Thread-Topic: Comment on draft-mills-sip-access-network-info-02
Thread-Index: AcIHG0fWrz9jnUVYR5SgnEfrng1KRg==
From: "Rob Phillips" <rob@netrake.com>
To: <sip@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id KAA16713
Subject: [Sip] Comment on draft-mills-sip-access-network-info-02
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

In section 7 "The P-Access-Network-Info header", the rules for 
	3gpp-cgi , and
	3gpp-utran-cell-id 
need to have their rule names changed.  RFC2234 section 2.1 specifies that rule names must start with an alpha character only, not an alphanum.  Might I suggest
	access-3gpp-cgi, and
	access-3gpp-utran-cell-id

- rob

--
Rob Phillips, Sr. Software Engineer                 Netrake Corporation
mailto: rob@netrake.com                           3000 Technology Drive
voice: (214) 291-1096                                         Suite 100
fax:   (214) 291-1010     http://www.netrake.com     Plano, Texas 75074


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



From daemon@optimus.ietf.org  Wed May 29 14:10:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27364
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 14:10:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA05126
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 14:11:14 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02547;
	Wed, 29 May 2002 13:45:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02513
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 13:45:16 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26504
	for <sip@ietf.org>; Wed, 29 May 2002 13:44:50 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4THi6420090;
	Wed, 29 May 2002 12:44:07 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>, <rohan@cisco.com>, <brian.rosen@marconi.com>,
        <jo@ipdialog.com>
Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
Date: Wed, 29 May 2002 12:43:23 -0500
Message-ID: <004b01c20738$5517a090$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <3CF4CA18.C875EE15@ericsson.com>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> > > > 2. Is there an implicit assumption that the registrar will 
> > > > register
> > > the
> > > > associated URI? I believe this is true in the 3gpp case. A UA 
> > > > probably needs to know whether they have been 
> registered or not. I 
> > > > would not
> > > want
> > > > to put a URI into a Reply-To header unless I knew it 
> was a valid 
> > > > URI
> > > for
> > > > receiving incoming calls....
> > >
> > > No, this is not the case. The "reg" event will provide such 
> > > information. But the semantics of this header is just to 
> provide a 
> > > set of IDs that the user has associated to the address-of-record. 
> > > They may or may not be registered,
> > > the user will know this information by other means 
> (subscription to the
> > > registration event package). The user knows that he can initiate
> > > registration
> > > of any of the returned IDs, or it can populate the From 
> with any of
> > > those
> > > IDs as well. That's it.
> > 
> > Presumably the UA will need to make sure that they are 
> registered; you 
> > should probably note in the draft that there is no 
> assumption that the 
> > associated URI are registered, and that if the UA wants that, it 
> > should check and perform the registrations if needed.
> 
> Miguel-> Done. I some text referencing the registration event package,
> as the mechanism to guess whether the associated URIs are 
> registered or not.

I think there's some confusion about what "registered" means for an
associated URI. URIs often work without anyone having sent a REGISTER
message associating a contact with them. For example, in my office,
9724735455@dynamicsoft.com is configured in my home server to forward to
dwillis@dynamcisoft.com. So,  9724735455@dynamicsoft.com is an
"associated URI" that might be included in the P-Associated-URI response
when dwillis@dynamicsoft.com registers.

The question of "does inclusion in a P-Associated-URI header mean that
the registrar registered that URI" is orthogonal to this draft and
completely out of scope. There may or may not be one or more
regisistations for each associated URI -- it just doesn't matter as far
as this draft is concerned.

I think from some of the comments that people are reading the draft
BACKWARDS.  This is not a mechanism by which a UA requests registratio
of additional URIs. This is a technique by which a registrar informs a
UA of aliases known to the registrar which will be forwarded to the UA.

>  
> > > > > 5.3 Procedures at the proxy
> > > > >
> > > > >    This memo does not define any procedures at the proxy.
> > > > >
> > > >
> > > > Well, presumably some proxy will enforce the list of 
> > > > associated-URI,
> > > and
> > > > reject requests that have a value in the From field not amongst 
> > > > the allowed set? Is there a new response code for that?
> > >
> > > Yes, the proxy will send a 403 Forbidden. However, I don't think 
> > > this is
> > >
> > > part of the scope of this I-D. I understand that the title 
> > > "Procedures at the proxy" are procedures related to the extension 
> > > (the header in this case).
> > > The idea in this I-D is to convey to the UA the list of 
> URIs that he can
> > > use
> > > in subsequent requests, not how to police them. 
> Therefore, there are not
> > > procedures at the proxy related to the P-Associated-URI header.
> > 
> > Well, its all intertwined. The associated-URI list is the 
> only way a 
> > UA has to retry if it should get this error, since it conveys the 
> > allowed URI in the first place. Actually, 403 is really NOT 
> the right 
> > response. If it gets this, how does the UA recover? It 
> needs to know 
> > that the problem was a disallowed From value, and it needs to know 
> > which ones are OK. I would argue that the way to deal with 
> this is a 
> > new response code that would contain in it the 
> Associated-URI header 
> > indicating which ones are allowed.

Actually, we're doing identity filtering, not From filtering. The UA
would presumbaly use a P-Asserted-Identity header to assert one of the
associated URIs on a new request.

We need to evaluate the following proposal in that context.
 
> There are two issues to solve here, namely:
> 1) Does the UAC need to know there was something wrong with one of the
>    headers? I would say, yes. And I agree that the proxy should return
>    the list of allowed IDs in the form of a P-Associated-URI.
> 2) Is 403 the best response code? I don't see why 403 is not a right
>    response code *if we add the P-Associated-URI* to the response in
>    the 403. Once must notice also that P- headers can't add a new 
>    response code.
> 
> So my proposal: the policy enforcement proxy returns a 403 
> response in case the URI in the From header or any other SIP 
> header value that 
> provides information of the identity of the calling party is not 
> populated with any of the allowable URIs. The proxy adds a 
> P-Associated-URI header with the complete list of allowable 
> URIs to the user. Is this correct?


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



From daemon@optimus.ietf.org  Wed May 29 15:37:14 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00570
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 15:37:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA12413
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 15:37:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10470;
	Wed, 29 May 2002 15:05:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA10439
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 15:05:50 -0400 (EDT)
Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29260
	for <sip@ietf.org>; Wed, 29 May 2002 15:05:24 -0400 (EDT)
Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7])
	by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id g4TJ2aLe015226
	for <sip@ietf.org>; Wed, 29 May 2002 15:02:36 -0400 (EDT)
Received: from dynamicsoft.com (NJ-AKRISTENSEN.dynamicsoft.com [63.113.46.198]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id LJW81ZN8; Wed, 29 May 2002 15:05:17 -0400
Message-ID: <3CF5266D.5030802@dynamicsoft.com>
Date: Wed, 29 May 2002 15:05:17 -0400
From: Anders Kristensen <akristensen@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: SIP <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-mills-sip-access-network-info-02.txt grammer
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Nit: the grammar seems to allow only one access-info parameter per 
P-Access-Network-Info header. Is that intentional?

Anders


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



From daemon@optimus.ietf.org  Wed May 29 15:58:16 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01324
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 15:58:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id PAA13527
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 15:58:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11604;
	Wed, 29 May 2002 15:29:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA11554
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 15:29:34 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00168
	for <sip@ietf.org>; Wed, 29 May 2002 15:29:10 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.13])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TJUQYH026664;
	Wed, 29 May 2002 15:30:26 -0400 (EDT)
Message-ID: <3CF52BF1.31047ADC@dynamicsoft.com>
Date: Wed, 29 May 2002 15:28:49 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dwillis@dynamicsoft.com>
CC: "'sip'" <sip@ietf.org>, rohan@cisco.com, brian.rosen@marconi.com,
        jo@ipdialog.com,
        "Jon Peterson (jon.peterson@NeuStar.com)" <jon.peterson@neustar.biz>
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
References: <00d901c2068f$1e0b4420$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Comments:

> Withholding the identity of a user will, among other
>    things, render the other parties in the dialog unable to send new SIP
>    requests to the user outside of the context of the current dialog.

Thats not necessarily true; I can remain anonymous and even get a call
back later on (for example, Reply-To: sip:user8222739@anonymous.net) -
the key is that my identity is never revealed.

> A display-name is a quoted string containing
>    a name for the identified user (for example, "Alice"). 

As a nit, display-names need not be quoted strings.

> The privacy problem is further complicated by proxy servers (also
>    referred to in this document as "intermediaries" or "the network")
>    that add headers of their own, such as the Record-Route and Via
>    headers. 

Its probably also worth referncing the identity work as another source
of identity information that can be inserted by proxies.

> The scope of these privacy requirements is solely the SIP protocol as
>    it is described in [1].  The mechanisms at the disposal of user
>    agents and proxy servers are restricted to those described in the SIP
>    specification.  Also, the privacy properties of the headers listed in
>    the core SIP specification alone, as opposed to headers defined by
>    any existing or planned extension, are considered here.

I don't quite understand this paragraph. If a future extension defines a
header that reveals identity information, shouldn't this draft cover
requests for privacy of that information?

> The
>    author maintains that these problems are sufficiently well addressed
>    in the baseline SIP specification and related documents, and that no
>    new mechanisms are required.

Minor nit - but as a working group draft, its not appropriate to make
statements about the opinions of the author, as the document represents
group consensus. Its sufficient to just strike "The author maintains
that".

> When a user voluntarily asserts an identity in a request, they are
>    claiming that they can receive requests sent to that identity in that
>    domain.

Thats a narrow definition of identity, particularly since the draft
discusses ip address privacy, which wouldn't qualify as an identity by
the above definition. Neither would a contact URI.

meta-comment: as the draft is a bit verbose, it might be helpful to have
in the introduction a paragraph or two which overviews the structure of
the document and discusses how the sections relate.

> The following SIP headers, when generated by a user agent, can
>    directly or indirectly reveal identity information about the
>    originator of a message: From, Contact, Reply-To, Via, Call-Info,
>    User-Agent, Organization, Subject, Call-ID, In-Reply-To

The sentence ends mid-stream.

Also, you have forgotten two very, very important ones - Authorization
and Proxy-Authorization. In general, I think the draft needs discussion
of these headers specifically. The user should only include such headers
if it is willing to provide identity information for the realm provided
in the challenge. Furthermore, the user may need to verify that the
proxy is indeed part of the realm that they claim to be from before the
user provides identity information to it. Right now, we have no real way
to do that unless the proxy is the first hop proxy, in which case TLS
can be used to ascertain the identity of the proxy that is providing the
challenge before providing credentials. All of this needs to be
discussed. The issue is similar to that of routing requests to privacy
services.

Also, you left off the Server header and the Warning header, both of
which can potentially (although unlikely) reveal identity information in
a response.

> destination of the message, users MAY also place legitimate values
>    for these headers in encapsulated 'message/sip' S/MIME bodies as
>    described in the SIP specification.

A reference to the specific section number would be useful here.

> Privacy-hdr  =  "Privacy" HCOLON priv-value *(COMMA priv-value)
>    priv-value   =   "header" | "session" | "user" | "none" | "critical" | token

I would strongly advise that you also allow for semi-colon separated
parameters for the purposes of future extensibility.

Also, you need to use slashes "/" to separate or-values, not vertical
bars "|".


> header: The user requests that a privacy service obscure those
>       headers cannot be completely expunged of identifying information
>       without the assistance of intermediaries (such as Via and
>       Contact). 

s/cannot/that cannot

>  Note that requesting session privacy when end-to-end session
>       encryption is not possible raises serious security concerns (see
>       Section 6.2).

Indeed. This is why I wrote
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt

which allows both to the extent that is possible.

>  Header field          where   proxy ACK BYE CAN INV OPT REG
>    ___________________________________________________________
>    Privacy                        amrd  o   o   o   o   o   -

I think privacy is still useful in a register message. It would be
helpful when I want to register through my provider using an anonymizer
service, which possibly obfuscates the Contact header. Interestingly,
the privacy service couldn't obfuscate the From or To field, since these
are needed by the registrar. Perhaps that is why Privacy is not allowed
here? It makes me wonder if there is a need to specify privacy on a
slighlty more granular level, allowing the user to request obfuscation
of groups of headers (To/From in one group, Contact/Via/RR in another).


Also, you need to explicitly specify the set of valid combinations of
the various privacy values; its not entirely clear from the text.

>  critical: The user asserts that the privacy services requested for
>       this message are critical, and that therefore, if these privacy
>       services cannot be provided by the network, this request should be
>       rejected.  Criticality cannot be managed appropriately for
>       responses.

OK, I hate to dredge up old issues, and perhaps this was hashed out in
the many privacy threads I didn't get to, but, it seems like the value
of critical is going to neccessitate a Proxy-Require header. The draft
makes no mention of the use of proxy-require or the protocol
implications if the extension is not supported by proxies. The
proxy-require can be removed once the services have been performed,
which is a good thing.

>    It is RECOMMENDED that service providers couple the privacy service
>    function with a local outbound proxy.  Users can thereby send their
>    messages that request privacy through their usual outbound route.
>    Users should not assume, however, that the administrative domain that
>    is the destination of the request would be willing and able to
>    perform the privacy service function on their behalf. 

How does the user know whether privacy services are supported? Do they
need to try it with Proxy-Require to see if the request fails? 

I also toyed with the idea of defining a URI parameter that indicated
that the URI represents a resource that can provide privacy functions,
similar to the way we have a URI parameter for indicating that a
resource can provide compression. However, I don't think this is a good
idea, but wanted to mention it for completeness.

> What a responding user agent can do, however, is ensure that the path
>    by which requests reach them traverses their privacy service.  In
>    some architectures, the privacy service function will be fulfilled by
>    the same server to which requests for the local administrative domain
>    are sent, and hence it will automatically be in the path of incoming
>    requests.  However, if this is not the case, the user will have to
>    ensure that requests are directed through a third-party privacy
>    service.  The simplest way to accomplish this is to procure a
>    'private' URI from the third-party service and to distribute this as
>    an address-of-record.  The user would then register their normal
>    address-of-record as a contact address with the third-party service.

Based on this, the third party privacy service would see the request
before their actual provider. I can imagine there are also cases where
the opposite makes more sense - the user registers their anonymous AOR
as a contact address with their actual provider. TO me, this makes more
sense. You want the privacy function closest to the user; in the case of
responses, that means that you want it to be the first element that gets
the response, which would motivate registering the anonymous AOR as a
contact with the actual provider.

Another means for providing anonymity of responses is to use a CPL
script to forward a request to the anonymization service. I think its
worth mentioning this as well.

This also raises the question of whether a privacy service is a "hop"
described by a URI in a route header, or is an identity, which would
appear in the request URI and be translated. Clearly, the assumption
above is the latter. Thats going to be true for some privacy services,
but for things like session privacy, I would argue that these are hops,
and they are ideally reached with URIs in route headers, not the
request-URI.


> The techniques described in this section do not extend to the
>    creation of falsified but plausible URIs and display-names that do
>    not identify the originator but may fool the remote party into
>    believing that the originator is not anonymous. 

Awkward - reword.

> If these headers require anonymization, the
>    user MUST request that service from an intermediary, namely a privacy
>    service.
> 

MUST seems overly strong in this case....

> For headers indicating how further requests in the current dialog
>    should be routed (such as the Contact header)

I think its useful to provide the full set, namely, Contact, Via, and
SDP addresses and hostnames.


I don't understand why section 5 is a separate section. Since its about
construct anonymous messages, it seems like it is naturally a subsection
of 4.1. This relates to my meta-comment about the verbosity of the
draft; it reads a bit too much like a dialog, and not quite enough like
a protocol specification. Section 5 is really describing normative
behavior for user agents, and belongs in the section which describes
that.

> This document defines a new SIP logical role called a "privacy
>    service".  The privacy service role is instantiated by a network
>    intermediary, frequently by entities that can act as SIP proxy
>    servers.  The function of a privacy service is to supply privacy
>    functions for SIP messages that cannot be provided by user agents
>    themselves.

I think its worth noting that privacy services are described by URIs
(see above comments on whether they are hop URIs or destination URIs)

> However, if the Privacy header value of
>    'none' is specified in a message, privacy services MUST NOT perform
>    any privacy function.

I have a feeling that the MUST NOT strength is going to be a problem for
these folks that claim they have a regulatory requirement to provide
privacy even when the user doesn't want it (or at least, I recall that
this was the claim).

>  Privacy services MUST implement the 'none' and 'critical' privacy
>    levels, and MAY implement any of other privacy levels described in
>    Section 4.2 as well as any extensions that are not detailed in this
>    document.

'critical' is not really a level, so much as a qualifier on all of the
other levels. 

> When a privacy service performs one of the functions corresponding to
>    a privacy level listed in the Privacy header, it SHOULD remove the
>    corresponding priv-value from the Privacy header - otherwise, any
>    other privacy service involved with routing this message might
>    unnecessarily apply the same function, which in many cases would be
>    undesirable.  When the last priv-value (not counting 'critical') has
>    been removed from the Privacy header, the entire Privacy header MUST
>    be removed from a message.

I am concerned about the complete removal of the privacy header. THe
problem is that downstream elements may insert additional identification
information into the request. I would propose that a new value for the
header be defined, say "no-add", which tells elements that they don't
need to modify any headers, but that they should not add any further
identification information to a request. If the header value was present
in a request, and is then performed by a proxy, the proxy changes that
value to no-add.

> Firstly, a request for header privacy entails that the server SHOULD
>    NOT add any of the following headers to the message: Call-Info,
>    Server, and Organization.  All of these provide optional information
>    that could reveal facts about the user that has request anonymity.
> 

I would make the statement more general, namely, it SHOULD NOT add any
headers which could reveal any identity information. For example,
Call-Info, Server and Organization.

> Privacy services operating on requests SHOULD remove all Via headers
>    that have been added to the request prior to its arrival at the
>    privacy service (a practice commonly referred to as "Via hiding")

No, its not "via hiding", which has a specific definition from rfc2543.
This is different; I would call it "via stripping". 

> Note
>    that the topmost such Via header in a request contains an IP address
>    or hostname that designates the originating client, and subsequent
>    Via headers may indicate hosts in the same administrative domain as
>    the client.

This is backwards. Its the bottom-most Via header value. Note also that
you should use the formal terminology - there is only one Via header,
but it has multiple values.

>  When a privacy service alters the Contact header of a
>    request, it MUST insert a Record-Route header pointing to itself so
>    that it can restore the appropriate contact address as necessary.

Thats not true. The Contact header will presumably route to itself, so
that an additional record-route is not necessary. 

> In a manner similar to Via hiding, a privacy service SHOULD also hide
>    any Record-Route headers that have been added to a request before it
>    reaches the privacy service.  Such Record-Route headers might also
>    divulge information about the administrative domain of the client.
>    Once Record-Route headers have been hidden, however, the privacy
>    service MUST add appropriate Route headers to future requests as
>    needed.

Given how easy it is to get this wrong, I would avise putting a bit more
text in there about properly constructing the route and record-routes. 

>  that are so removed, which requires the privacy service to keep a
>    pretty significant amount of state on a per-session basis. 

Its per-dialog. Its worth noting that forking could create multiple
dialogs, each of which would then need to be managed.

> Note that the privacy service MUST remove any non-essential
>    informational headers that have been added by the client, including
>    the Subject, Call-Info, Organization, User-Agent, Reply-To and In-
>    Reply-To.

You use the term client here, which would imply that this is only for
requests. Since the spec is generally request/response agnostic, you
need to use the term "user agent". I suspect there are other instances
of things like this too; I personally read most of the draft with
requests in mind. Its worth doing a pass on the document with responses
in mind to make sure its correct.

> Therefore, any time that a privacy service needs to modify any
>    dialog-matching headers for privacy reasons, it SHOULD act as a
>    transparent back-to-back user agent

This was discussed on the list; the term transparent B2BUA is not
defined in bis or in this document. You need to be more exact in your
definitions.

> Note that authentication mechanisms, including the Digest
>    authentication method described in the SIP specification, are outside
>    the scope of the privacy considerations in this document.  Revealing
>    identity through authentication is highly selective, and may not
>    result in the compromise of any private information.  Obviously,
>    users that do not wish to reveal their identity to servers that issue
>    authentication challenges MAY elect not to respond to such
>    challenges.

Ah, here is some text on Proxy-Auth and Auth. I disagree that these are
outside the scope of the spec, and I think they deserve discussion along
the lines I have outlined above.

> IANA Considerations
> 
>    This document defines a new SIP header called "Privacy" that allows a
>    user agent to request a certain degree of privacy for a message.
>    This header is defined in Section 4.2.

I am a big fan of very explicit IANA considerations sections. I would
recommend you format this section as an outline, like this:

  Header Name to be Registered:  Privacy
  
  RFC of Specification: RFC XXXX [Note to RFC Editor: please replace
XXXX with the RFC number of this specification]

  Compact Form: none defined

By the way, do we want to define a compact form?

> The current values of the "Privacy" header are restricted to
>    'header', 'session', 'user', 'none' and 'critical'.  However, further
>    values for the "Privacy" header can be defined in RFCs approved by
>    the SIP working group.  IANA registration for these "Privacy" header
>    field values is required.

If you are setting up an IANA registry for these values, you are going
to need more detail than this. See the sip-events spec for a good
example of how to define an IANA registry.


THanks,
Jonathan R.








Dean Willis wrote:
> 
> We need to do a quick review of the general privacy draft developed out
> of our discussion in Las Vegas.
> 
> Please send any issues to the list and the editor IMMEDIATELY.
> 
> The draft is available from:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.
> html
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.
> txt
> And soon to be available from internet-drafts if not already . . .
> 
> --
> 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

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

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



From daemon@optimus.ietf.org  Wed May 29 16:21:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01923
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 16:21:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA14869
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 16:21:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13038;
	Wed, 29 May 2002 15:49:15 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA13007
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 15:49:13 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01040
	for <sip@ietf.org>; Wed, 29 May 2002 15:48:47 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.13])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TJjqYH026677;
	Wed, 29 May 2002 15:45:52 -0400 (EDT)
Message-ID: <3CF52F8F.687A0636@dynamicsoft.com>
Date: Wed, 29 May 2002 15:44:15 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>, sip@ietf.org,
        rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com
Subject: Re: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
References: <004b01c20738$5517a090$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Dean Willis wrote:
> 
> > > Presumably the UA will need to make sure that they are
> > registered; you
> > > should probably note in the draft that there is no
> > assumption that the
> > > associated URI are registered, and that if the UA wants that, it
> > > should check and perform the registrations if needed.
> >
> > Miguel-> Done. I some text referencing the registration event package,
> > as the mechanism to guess whether the associated URIs are
> > registered or not.

Miguel - there is no need to use the registration event package for
this. You can simply send a REGISTER request with the associated URI in
the To field, and the registrar will return any registerd contacts. 

> 
> I think there's some confusion about what "registered" means for an
> associated URI. URIs often work without anyone having sent a REGISTER
> message associating a contact with them. For example, in my office,
> 9724735455@dynamicsoft.com is configured in my home server to forward to
> dwillis@dynamcisoft.com. So,  9724735455@dynamicsoft.com is an
> "associated URI" that might be included in the P-Associated-URI response
> when dwillis@dynamicsoft.com registers.
> 
> The question of "does inclusion in a P-Associated-URI header mean that
> the registrar registered that URI" is orthogonal to this draft and
> completely out of scope. There may or may not be one or more
> regisistations for each associated URI -- it just doesn't matter as far
> as this draft is concerned.
> 
> I think from some of the comments that people are reading the draft
> BACKWARDS.  This is not a mechanism by which a UA requests registratio
> of additional URIs. This is a technique by which a registrar informs a
> UA of aliases known to the registrar which will be forwarded to the UA.

Whether the forwarding is created as a result of a binding to another
URI, or through an implicit registration (whcih is really the same thing
anyway), I thought Miguel was saying that there was no assumption about
this URI being usable to receive requests. 


> > > > procedures at the proxy related to the P-Associated-URI header.
> > >
> > > Well, its all intertwined. The associated-URI list is the
> > only way a
> > > UA has to retry if it should get this error, since it conveys the
> > > allowed URI in the first place. Actually, 403 is really NOT
> > the right
> > > response. If it gets this, how does the UA recover? It
> > needs to know
> > > that the problem was a disallowed From value, and it needs to know
> > > which ones are OK. I would argue that the way to deal with
> > this is a
> > > new response code that would contain in it the
> > Associated-URI header
> > > indicating which ones are allowed.
> 
> Actually, we're doing identity filtering, not From filtering. The UA
> would presumbaly use a P-Asserted-Identity header to assert one of the
> associated URIs on a new request.
> 
> We need to evaluate the following proposal in that context.

I don't see how that changes anything.

Anyway, I am not going to push it in the interests of limitng the scope
of p-headers. If everyone says that the ability to reject isn't needed,
its not needed, and so be it.

-Jonathan R.

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

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



From daemon@optimus.ietf.org  Wed May 29 16:33:37 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02377
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 16:33:37 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA16013
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 16:34:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14198;
	Wed, 29 May 2002 16:04:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14170
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 16:04:26 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01484
	for <sip@ietf.org>; Wed, 29 May 2002 16:03:58 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.13])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TK58YH026738;
	Wed, 29 May 2002 16:05:08 -0400 (EDT)
Message-ID: <3CF53413.20FF612B@dynamicsoft.com>
Date: Wed, 29 May 2002 16:03:31 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com,
        ehenrikson@lucent.com
Subject: Re: [Sip] Poll: expert review of 
 draft-henrikson-sip-charging-information
References: <00b301c20359$0e1bf0c0$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

First off, I have to apologize for the lateness of these comments. Given
the scope of my comments, I should have raised them earlier. 

I have some serious concerns about this draft.

Most notably, I disagree entirely with the assessment that the problem
isn't entirely solved by loose routing. When the S-CSCF sends a request
to an application server, it ought to be inserting two loose routes -
one that points to the AS, and another that points back to itself,
containing whatever context is needed for the S-CSCF to do what it needs
to do from that point forward. The draft makes the following statement:

>  One may consider using the Route header as a mechanism to get the 
>     request sent back to the S-CSCF.  However, Route headers don't 
>     automatically transit an AS acting as a B2BUA. This could be 
>     overcome by using loose-routing and application logic in the B2BUA.  
>     But that is not the full problem to be solved. A strong correlation 
>     of dialogs is also needed for accounting purposes to treat the 
>     sequence of dialogs as a concatenated single dialog. A common 
>     identification tag needs to be carried in each related dialog so 
>     that the charging functions can associate all the dialogs. 

A smart B2BUA will not discard loose routes, particularly not one thats
used in 3gpp for this reason exactly. Thus, the principal motivation
given, being able to corelate incoming INVITEs from outgoing ones in a
spiral - is not correct. We explicitly designed the loose routing stuff
to enable exactly this kind of function (remember the Bjorkner service
route draft?).

The other argument that is given here - correlation of dialogs for
accounting purposes - makes no sense to me. The route header provides
the ability for the S-CSCF to completely correlate the incoming INVITE
to the one it sent out. It therefore has all the information it needs to
account for the calls and to know which applications are invoked. 

The last thing I want to do is specify two ways of doing the same thing.
Given that this kind of correlation is square in the sights of loose
routing, I am concerned about the overlap.

-Jonathan R.

Dean Willis wrote:
> 
> You may recall that we're doing an Expert Review of
> draft-henrikson-sip-charging-information.
> 
> If you have a strong opinion for, against, or supporting a need for
> further work, or any further suggestions for enhancement, please post
> them now.
> 
> --
> 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

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

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



From daemon@optimus.ietf.org  Wed May 29 17:06:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03372
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 17:06:02 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA18628
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 17:06:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16428;
	Wed, 29 May 2002 16:44:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16385
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 16:44:02 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02604
	for <sip@ietf.org>; Wed, 29 May 2002 16:43:35 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4TKgl421240;
	Wed, 29 May 2002 15:42:48 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Miguel A. Garcia'" <Miguel.A.Garcia@ericsson.com>
Cc: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Michael Thomas'" <mat@cisco.com>, <sip@ietf.org>, <rohan@cisco.com>,
        <brian.rosen@marconi.com>, <jo@ipdialog.com>
Subject: RE: [Sip] Poll: expert review of draft-garcia-sip-associated-uri
Date: Wed, 29 May 2002 15:42:03 -0500
Message-ID: <000001c20751$4b4bcf00$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <3CF4CBEB.42321922@ericsson.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Miguel A. Garcia [mailto:Miguel.A.Garcia@ericsson.com] 
> Sent: Wednesday, May 29, 2002 7:39 AM
> To: Dean Willis
> Cc: 'Jonathan Rosenberg'; 'Michael Thomas'; sip@ietf.org; 
> rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com
> Subject: Re: [Sip] Poll: expert review of 
> draft-garcia-sip-associated-uri
> 
> 
> Dean Willis wrote:
> > 
> > > Michael Thomas wrote:
> > > >
> > > > So, I have a really dumb question. Why don't you
> > > > limit the number of assertable identities by 
> cryptographic means? 
> > > > That is, if I can't prove that I own an identity 
> binding, it gets 
> > > > dumped on the floor?
> > >
> > > Sure; I think the issue (Miguel can correct me if I'm wrong), is 
> > > that the UA needs to be configured with the set of 
> identities it can 
> > > claim in the first place. The same credentials would 
> allow the user 
> > > to assert any one of those, but the phone needs to know which it 
> > > should present to the user to use.
> > 
> > It goes a little further than this. We're also informing 
> the UA of a 
> > number of extisting "aliases". The UA can expect to see calls "To:" 
> > any of these aliases, and needs to delivery them 
> appropriately to the 
> > user as direct calls rather than as calls targeted 
> originally to some 
> > other user that have just been forwarded here. This might interact 
> > with distinctive-ringing features, for example.
> 
> I don't know where did you get this information, but as far 
> as I know, what you are saying is not within the scope of the 
> draft. You are 
> assuming an implicit 3rd party registration of all the 
> associated URIs. And I have just added some text to the draft 
> to clarify that this is 
> not the case. The associated URIs, in the general case, are 
> not implicitly registered. The UAC should use other 
> mechanism, such as a subscription to its own registration 
> event to guess it.

No. I'm assuming that any issue of registering an associated URI is
completely outside of the scope of this draft. The fact that an
associated URI is returned by a registrar has NO INDICATION WHATSOEVER
on the registration state of an associated URI. All that is being
claimed is that the given URI is associated with the tAOR of the
registration request.

The UA might assert an associated URI in making a new request.

The associate URI might be used to make a new request to the UA.

Both of these uses are outside the scope of this draft.

Incidentally, I don't believe that subscribing to the registration state
of a specific AOR will return anything about the registration state of
other AORs that have the first AOR as a Contact or have the same Contact
as that first AOR. Instead, I think you actually need to subscribe to
the registration state of the AOR in question.

--
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 daemon@optimus.ietf.org  Wed May 29 17:27:08 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03952
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 17:27:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA19506
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 17:27:32 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18549;
	Wed, 29 May 2002 17:04:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18523
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 17:04:45 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03290
	for <sip@ietf.org>; Wed, 29 May 2002 17:04:20 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.13])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4TL5oYH026802
	for <sip@ietf.org>; Wed, 29 May 2002 17:05:50 -0400 (EDT)
Message-ID: <3CF5424D.949B5346@dynamicsoft.com>
Date: Wed, 29 May 2002 17:04:13 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@ietf.org
References: <200205291132.HAA10977@ietf.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
Subject: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Comments on this draft:

The title needs to have the acronym SIP expanded.

The abstract reads oddly; it seems like a sentence has been misplaced:

> 1. Abstract 
>    This mechanism is useful in SIP networks that provide layer 2/layer 
>    3 connectivity through different access technologies. SIP User 
>    Agents 
>    This document defines the private SIP extension header P-Access-
>    Network-Info. may use this header to relay information about the 
>    access technology to serving proxies in their home network.

I think "SIP User Agents" needs to be moved before "may use this header"


The applicability statement is not quite right. It needs to capture the
specific assumptions and scenarios which limit the scope of this draft.
I would propose something like the following:

"This draft is appropriate in environments where SIP services are
dependent on a SIP elements knowing details about the IP and lower layer
technologies used by a UA to connect to the SIP network. Specifically,
the extension requires that the UA know the access technology it is
using, and that a proxy desires such information to provide services.
Generally, SIP is built on the "Everything over IP and IP over
Everything" principle, where the access technology is not relevant for
the operation of SIP. Since SIP systems generally should not care or
even know about the access technology, this draft is not for general SIP
usage. 

The information revealed in the P-Access-Network-Info header is
potentially very sensitive. Proper protection of this information
depends on the existence of specific business and security relationships
amongst the proxies that will see messages containing this header. It
also depends on explicit knowledge of the UA on the existence of those
relationships. Thefefore, this mechanism is only appropriate in
environments where the appropriate relationships are in place, and the
UA has explicit knowledge that they exist."

> Other examples include a laptop connected to a 
>    wireless LAN at an airport, or a laptop connected to a local ISP 
>    from a hotel room. 

I have to agree with Bob's assessment that the appropriate business
relationships will not be in place between the proxy at the airport and
the proxy in my home network. Therefore, this example is really not
appropriate.

> For instance, 
>    the type of access being used may influence home network decisions 
>    on what level of security to apply to sessions. 

I don't see what the access network has to do with session level
security (or what proxies have to do with session level security).

> It may be desired that the home network have the knowledge of some 
>    information relating to the network that provided access to the 
>    service. 

This sentence is awkward, I suggest rewording to "The home network may
desire knowledge about the access network."


The introduction and overview aren't really different. I would suggest
moving the overview into the introduction, and have a separate "Overview
of Operations" section which overviews the basic operation of the
extension. That section is fairly short, since the extension is simple.
Something like:

---
Overview of Operation

This section provides an overview of the operation of this extension,
and is not normative in nature.

When a user agent generates a SIP request which it knows is going to be
securely sent to its home network, it inserts a P-Access-Network-Info
header into the request. This header contains information on the access
network that the UA is using to get IP connectivity. The header is
ignored by intermediate proxies between the UA and the home proxy. The
home proxy can inspect the header and make use of the information
contained there to provide services. Before proxying the request
onwards, the home proxy strips the header from the request.
---

> The P-Access-Network-Info header MAY be inserted by a UA. Proxies, 
>    MUST NOT add to or modify the contents of the P-Access-Network-Info. 

This text appears in the section that describes teh syntax and values of
the P-header. Generally (as we learned with bis), its better to place
normative behavior in one place. Therefore, I suggest you move any
normative behavior like this into section 8. Section 7 should remain
nothing more than a description of the syntax of the header and the
meaning of the various parameters.

> The proxy in the home network may act upon any information in the P-
>    Access-Network-Info header if it is present, to provide a different 
>    service  depending on the network through which the UA is accessing 
>    the server. For example, for cellular radio access networks the home 
>    network may use the cell ID to provide basic localised services. 
>     
>    A proxy in the home network MUST delete the header before forwarding 
>    the message outside of its own administrative network domain or 
>    outside a trusted administrative network domain. 

this text belongs in 8.2.

> Some systems may require that the P-Access-Network-Info header is 
>    only sent by the UAC when a secure connection to the proxy in the 
>    home network is present.  For example, in 3GPP systems, the UAC MUST 
>    NOT send this header in the initial unauthenticated REGISTER 
>    request. 

this text belongs in 8.1.

> A UAC supporting this extension may be capable of accessing the 
>    services provided by its home network via one or more access 
>    technologies. 

This sentence sort of states the obvious. Obviously the UAC is capable
of accessing the SIP network through some access technology.


> Such a UAC must know the values to use for each type 
>    of supported access technology. The means of this determination are 
>    outside the scope of this document. 

this belongs in section 8.1. 

> The home network must know the possible values that a particular UA 
>    may use to populate the access-type and access-info fields. 
>     
>    In other words, a home network with business agreements allowing 
>    users to access via a particular technology must be able to parse 
>    the P-Access-Network-Info header containing an access-type for that 
>    technology in order to use this information. 
>     
>    For example, the access-type could read "IEEE-802.11b".  If a home 
>    network knows it has a business agreement with a W-LAN access 
>    network, it must be ready to understand the value "IEEE-802.11b". 
>    Similarly, a UAC supporting this extension that can access via W-LAN 
>    must be able to insert the relevant value. 

This text confuses me, since it tries to belabor an obvious point - that
the proxy must know how to parse these values. Maybe I am missing
something. Perhaps this is related to the fact that no definition is
provided for 3gpp-cgi and 3gpp-utran-cell-id? I don't see why you can't
just provide a definition for those and then delete the statements
above.

> A UAC that supports this extension and is willing to disclose the 
>    related parameters MAY insert the P-Access-Network-Info header in 
>    any SIP message request. 

You probably need to provide some guidance on when it ought to be doing
that. I have a suspicion that you do have specific requirements (like,
every request in order to keep cell-id up to date). 

> This document does not define either the nature of the information 
>    or the messages where the P-Access-Network-Info needs to be 
>    inserted. 

This is confusing; it does define the nature of the information. What am
I missing?


> A proxy, typically located in the home network, and therefore 
>    trusted, MUST delete the header when the SIP signaling is forwarded  
>    to a SIP server located in a non-trusted administrative network 
>    domain. The access network information is used by a home network and 
>    is of no interest to the destination 
>    network. 

What about a trusted administrative network domain? I think that the
home proxy MUST strip this in all cases.

>  This extension assumes that the access network is trusted by the UA 
>    (because the UAÆs home network has a trust relationship with the 
>    access network), as described in section 7. 

The trust relationship is not between the access network and the home
network. The assumption is that there is a trust relationship between
the UA and the proxy it sends the request to, and then between all
proxies between the outbound proxy and the home proxy.

>  The home network uses the information contained in this header to 
>    provide additional services  and 

This sentence ends mid-stream.

>  UAs are expected to provide correct information.  However, there are 
>    no security problems resulting from a UAC inserting incorrect 
>    information. 

Well, I doubt that is true in the case of cell-id. Providing false
location information can be used for all sorts of bad things.

Thanks,
Jonathan R.



Internet-Drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
>         Title           : The SIP Access Network Info header
>         Author(s)       : D. Mills
>         Filename        : draft-mills-sip-access-network-info-02.txt
>         Pages           : 8
>         Date            : 28-May-02
> 
> This mechanism is useful in SIP networks that provide layer 2/layer
> 3 connectivity through different access technologies. SIP User
> Agents
> This document defines the private SIP extension header P-Access-
> Network-Info. may use this header to relay information about the
> access technology to serving proxies in their home network. The
> serving proxy may then use this information to optimize services for
> the UA. For example, a 3GPP terminal uses this header to pass
> information about the access network such as radio access technology
> and cell ID to its home service.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-mills-sip-access-network-info-
> 02.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the
> message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-mills-sip-access-network-info-02.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         mailserv@ietf.org.
> In the body type:
>         "FILE
> /internet-drafts/draft-mills-sip-access-network-info-02.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ------------------------------------------------------------------------
> 
> Subject:
> Date: Wed, 29 May 2002 10:32:52 -0400
> 
>   ------------------------------------------------------------------------
> 
>    ATT38948.txtName: ATT38948.txt
>                Type: Plain Text (text/plain)
> 
>                 Access-Type: anon-ftp
>  Document Info:        Site: internet-drafts
>                        Mode: ftp.ietf.org

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

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



From daemon@optimus.ietf.org  Wed May 29 18:32:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05792
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 18:32:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA23487
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 18:32:47 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22030;
	Wed, 29 May 2002 18:11:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA22003
	for <sip@optimus.ietf.org>; Wed, 29 May 2002 18:11:05 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05374
	for <sip@ietf.org>; Wed, 29 May 2002 18:10:42 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g4TMAsX82466;
	Wed, 29 May 2002 17:10:54 -0500 (CDT)
Message-ID: <3CF551D1.6080100@dynamicsoft.com>
Date: Wed, 29 May 2002 17:10:25 -0500
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>, sip <sip@ietf.org>
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
X-Enigmail-Version: 0.49.5.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Some comments. My mail reader didn't want to cooperate on quotes--the 
text between "" is from the draft.

Most of these are really nits


"Note that there is a fine line between identity fraud and humor in some 
cases. Many email clients by default render to the user only the 
display-name of the sender of a message. It is easy to populate the 
display-name in a way that many would consider abusive; it is best not 
to select any display-name that may suggest an attempt to impersonate 
someone else."

This section sounds like something that belongs in a bcp, not in a draft 
that I assume is intended to become a normative RFC.

"From the former [sip:jon.peterson@neustar.biz], the full name and 
employer of the party in question can easily be gleaned. From the 
latter, you learn nothing other than that the party desires anonymity. 
In some cases, sufficient anonymity can be achieved by selecting an 
oblique URI. Today, the SIP specification recommends a URI with 
"anonymous" in the user portion of the From header."

Hmm, I fear someone might read this and believe too much, that is, that 
they could really know the identity of the sender from a URL in a From 
header. For example, _I_ could use that URL. If you glean something from 
it, you would glean wrong. (Perhaps s/glean/guess would be sufficient here.)

"For these reasons, the hostname value 'anonymous.invalid' SHOULD be 
used for anonymous URIs. The full recommended form of the From header 
for anonymity is (note that this From header, like all others, MUST 
contain a valid and unique 'tag=' parameter): "

Does this require reserving anonymous.invalid to never resolve to 
something real? How would you enforce that? (Maybe a new TLD for 
"invalid" :-)  )

"If the 'critical' privacy level is present in the Privacy header of a 
request, then if the privacy service is incapable of performing all of 
the levels of privacy specified in the Privacy header then it MUST 
either fail the request, or it MUST forward the request to another 
privacy service which can fulfill these functions (note that before 
forwarding the request, the privacy service SHOULD complete a subset of 
the functions if it can). "

This one scares me a little. It implies that, even if I have gone to a 
great deal of trouble to directly talk to a privacy service (perhaps 
over TLS) and specify "critical", it can still forward the request 
without having performed privacy services. Doesn't this brings up the 
whole transitity of trust and trust boundery issue that we keep getting 
bogged down on?

"Firstly, a request for header privacy entails that the server SHOULD 
NOT add any of the following headers to the message: Call-Info, Server, 
and Organization. All of these provide optional information that could 
reveal facts about the user that has request anonymity. "

I would be happier if the situations that would allow the server to 
insert one of those headers were enumerated. More of a "MUST NOT unless" 
form. I tend to think it should be "MUST NOT unless it is impossible to 
fulfill the SIP request without doing so."

"Privacy services would be wise to authenticate users before providing a 
privacy function. To downstream entities, the privacy service will be 
the only responsible party to whom anonymous messages can be traced, and 
in abuse cases the privacy service could be held accountable for the 
actions of parties that it shelters. "

I'm not sure I agree with this. In some cases, _not_ authenticating 
might be the only defence against sopoena(sp?). This paragraph falls 
into the area of legal advice that should be given by lawers.


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



From daemon@ns.ietf.org  Wed May 29 21:14:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09747
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 21:14:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA03771
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 21:15:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01227;
	Wed, 29 May 2002 20:55:01 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01161
	for <sip@ns.ietf.org>; Wed, 29 May 2002 20:54:56 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09158;
	Wed, 29 May 2002 20:54:30 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4U0sQ423048;
	Wed, 29 May 2002 19:54:26 -0500
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: <internet-drafts@ietf.org>, <iesg-secretary@ietf.org>, <sip@ietf.org>
Date: Wed, 29 May 2002 19:53:40 -0500
Message-ID: <002201c20774$70d3ba80$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] Draft-willis-sip-path revised to -08
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Bernie and I just released what we hope is the REALLY final version of
the Path draft. This includes all feedback (mostly nits) so far from
IETF Last Call. For example, I spelled out "Session Initiation Protocol"
in the title.

Material available from:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-08.html
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-08.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-08.xml

And will be available from internet-drafts shortly, I expect.

--
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 daemon@ns.ietf.org  Wed May 29 21:18:43 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09808
	for <sip-archive@odin.ietf.org>; Wed, 29 May 2002 21:18:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id VAA04025
	for sip-archive@odin.ietf.org; Wed, 29 May 2002 21:19:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01219;
	Wed, 29 May 2002 20:55:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01156
	for <sip@ns.ietf.org>; Wed, 29 May 2002 20:54:56 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09157;
	Wed, 29 May 2002 20:54:30 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4U0sQ423049;
	Wed, 29 May 2002 19:54:26 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: <internet-drafts@ietf.org>, <sip@ietf.org>
Date: Wed, 29 May 2002 19:53:40 -0500
Message-ID: <002101c20774$70d0ad40$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-willis-sip-scvrtdisco revised to -06
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Bernie and I just released what we hope is the final version of the
Service Route Discovery draft.

This version fixes some syntax errors in the examples. I also cleaned up
the grammar slightly.

New stuff at:

http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.htm
l
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.txt
http://www.softarmor.com/sipwg/drafts/draft-willis-sip-scvrtdisco-06.xml


--
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 daemon@ns.ietf.org  Thu May 30 00:53:42 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13984
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 00:53:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id AAA15532
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 00:54:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14089;
	Thu, 30 May 2002 00:28:07 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14062
	for <sip@ns.ietf.org>; Thu, 30 May 2002 00:28:04 -0400 (EDT)
Received: from rautu.eng.song.fi (mail@p8-vanraj-ra12.teliafi.net [195.10.137.72])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13398
	for <sip@ietf.org>; Thu, 30 May 2002 00:27:34 -0400 (EDT)
Received: from jh by rautu.eng.song.fi with local (Exim 3.12 #1 (Debian))
	id 17DBGe-00007i-00; Thu, 30 May 2002 00:46:04 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15605.19484.700710.415050@rautu.eng.song.fi>
Date: Thu, 30 May 2002 00:46:04 +0300
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: Cullen Jennings
	 <fluffy@cisco.com>, sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00
In-Reply-To: <70565611B164D511957A001083FCDD5601870375@va02.va.neustar.com>
References: <70565611B164D511957A001083FCDD5601870375@va02.va.neustar.com>
X-Mailer: VM 7.00 under Emacs 21.1.1
From: Juha Heinanen <jh@lohi.eng.song.fi>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Peterson, Jon writes:

 > "Hint", for whatever reason, is the term that has stuck throughout this
 > discussion. There are meaningful cases in which a network would elect to use
 > some identity other than that hinted by the user, so I don't feel this term
 > is entirely inappropriate.

looks like my values differ from yours.  i as a service provider have to
respects the user's wish.  if there is many, i simply can't pick an
identity for a user on my own.  also, if the users wish conflicts with
his subscription, i must clear the call.

 > There is a concept, though one that is not discussed extensively in the
 > draft, that a user authenticates themselves in some fashion to the network.
 > The Spec(T) example in the draft suggests SIP Digest authentication, if I
 > recall. The P-Asserted-Identity could be populated based on an identity
 > expressed in that authentication process, rather than a From header, in the
 > absence of a hint (although admittedly in some networks the authentication
 > will not supply a usable identity as such). This applies equally to cases in
 > which the user has supplied an anonymous From header. This would seem to
 > provide a credible alternative to the MUST that you suggest below, one that
 > I see no reason to rule out.

that doesn't work if the user has multiple sip identities.

 > The short-term identity work puts the network, not the user, firmly in the
 > driver's seat. 

sounds a very bellhead approach to me.  if the user claims to be someone
that conflicts with the idea of the network regarding who the user
should be, then the network should not make things up, but deny 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 daemon@optimus.ietf.org  Thu May 30 07:51:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00015
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 07:51:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA18695
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 07:52:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17189;
	Thu, 30 May 2002 07:27:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17089
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 07:27:41 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29274;
	Thu, 30 May 2002 07:27:14 -0400 (EDT)
Message-Id: <200205301127.HAA29274@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 30 May 2002 07:27:13 -0400
Subject: [Sip] I-D ACTION:draft-garcia-sip-called-party-id-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private  Session Initiation Protocol extension for 
                          Called Party Identity
	Author(s)	: M. Garcia
	Filename	: draft-garcia-sip-called-party-id-02.txt
	Pages		: 8
	Date		: 29-May-02
	
This memo describes a private extension to SIP in the form of a
P-Called-Party-ID header. A proxy inserts this header typically in an
INVITE, en-route to its destination. The header is populated with the
Request-URI received by the proxy in the request. The UAS identifies
which ID out of several IDs the invitation was sent to (for example,
the user may be using simultaneously a personal and a business SIP URI
to receive invitation to sessions). The UAS may use the information to
render different distinctive audiovisual alerting tones, depending on
the ID used to receive the invitation to the session.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-garcia-sip-called-party-id-02.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Thu May 30 07:52:50 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00062
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 07:52:50 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA18775
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 07:53:17 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17241;
	Thu, 30 May 2002 07:27:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17205
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 07:27:55 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29292;
	Thu, 30 May 2002 07:27:20 -0400 (EDT)
Message-Id: <200205301127.HAA29292@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 30 May 2002 07:27:20 -0400
Subject: [Sip] I-D ACTION:draft-garcia-sip-visited-network-id-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private Session Initiation Protocol extension for 
                          Visited Network Identifier
	Author(s)	: M. Garcia
	Filename	: draft-garcia-sip-visited-network-id-02.txt
	Pages		: 7
	Date		: 29-May-02
	
This memo describes a private extension to SIP in the form of a
P-Visited-Network-ID header. The contents of the header identify each
of the visited networks the message traversed en-route to the home
network.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-garcia-sip-visited-network-id-02.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Thu May 30 08:45:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01832
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 08:45:44 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA23919
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 08:46:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21991;
	Thu, 30 May 2002 08:27:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21963
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 08:27:24 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01264
	for <sip@ietf.org>; Thu, 30 May 2002 08:26:56 -0400 (EDT)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0GWX00101BWCEU@siemenscomms.co.uk> for sip@ietf.org;
 Thu, 30 May 2002 13:26:36 +0100 (BST)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0GWX00NLCBWC2I@siemenscomms.co.uk> for sip@ietf.org; Thu,
 30 May 2002 13:26:36 +0100 (BST)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <L6A2FXKY>; Thu, 30 May 2002 13:26:51 +0100
Content-return: allowed
Date: Thu, 30 May 2002 13:26:25 +0100
From: "Elwell, John" <John.Elwell@siemenscomms.co.uk>
Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general
To: "'sip'" <sip@ietf.org>
Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BC@Beex50.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

   "When a privacy service performs one of the functions corresponding to
   a privacy level listed in the Privacy header, it SHOULD remove the
   corresponding priv-value from the Privacy header - otherwise, any
   other privacy service involved with routing this message might
   unnecessarily apply the same function, which in many cases would be
   undesirable."

This seems to be in contradiction with draft-ietf-sip-asserted-identity,
which show "Privacy: id" being maintained with the forwarded INVITE.

   "When the last priv-value (not counting 'critical') has
   been removed from the Privacy header, the entire Privacy header MUST
   be removed from a message."

Is this wise in the case of "None"?

--------------------------------------------------------------
John Elwell (john.elwell@siemens.com)
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.




> -----Original Message-----
> From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> Sent: 28 May 2002 22:32
> To: 'sip'
> Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; Jon
> Peterson (jon.peterson@NeuStar.com)
> Subject: [Sip] WGLC for draft-ietf-sip-privacy-general
> 
> 
> 
> We need to do a quick review of the general privacy draft 
> developed out
> of our discussion in Las Vegas.
> 
> Please send any issues to the list and the editor IMMEDIATELY.
> 
> The draft is available from:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g
> eneral-00.
> html
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g
eneral-00.
txt
And soon to be available from internet-drafts if not already . . .


--
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 daemon@optimus.ietf.org  Thu May 30 08:57:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02237
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 08:57:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id IAA24717
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 08:57:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22674;
	Thu, 30 May 2002 08:32:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22647
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 08:32:10 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01424
	for <sip@ietf.org>; Thu, 30 May 2002 08:31:43 -0400 (EDT)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0GWX00101C4BN5@siemenscomms.co.uk> for sip@ietf.org;
 Thu, 30 May 2002 13:31:23 +0100 (BST)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0GWX00NPXC4B2I@siemenscomms.co.uk> for sip@ietf.org; Thu,
 30 May 2002 13:31:23 +0100 (BST)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <L6A2FXNR>; Thu, 30 May 2002 13:31:38 +0100
Content-return: allowed
Date: Thu, 30 May 2002 13:31:13 +0100
From: "Elwell, John" <John.Elwell@siemenscomms.co.uk>
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
To: "'sip'" <sip@ietf.org>
Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BD@Beex50.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

Section 5, 3rd paragraph:
   "The proxy MAY add a P-Asserted-Identity header field with either a
   single SIP URI or a single SIPS URI.  Likewise, the proxy MAY add a
   P-Asserted-Identity header field with a single tel URL."

This seems to imply that a proxy can add a header even if there is already a
header of the type concerned. Presumably this should not be allowed.

--------------------------------------------------------------
John Elwell (john.elwell@siemens.com)
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.




> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 28 May 2002 22:32
> To: 'sip'
> Cc: brian.rosen@marconi.com; rohan@cisco.com; jo@ipdialog.com; 'Cullen
> Jennings'
> Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
> 
> 
> 
> We need to do a quick working group last call on the 
> "Asserted Identity"
> draft.
> 
> Please submit comments to the list and draft editor IMMEDIATELY.
> 
> Draft available from:
> 
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-
identity-0
0.html
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0
0.txt

And soon to be in the internet-drafts archive.

--
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 daemon@optimus.ietf.org  Thu May 30 09:39:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04253
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 09:39:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA29259
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 09:40:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26975;
	Thu, 30 May 2002 09:16:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28560
	for <sip@ns.ietf.org>; Wed, 29 May 2002 20:21:57 -0400 (EDT)
Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08369
	for <sip@ietf.org>; Wed, 29 May 2002 20:21:32 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4U0LQS28586
	for <sip@ietf.org>; Wed, 29 May 2002 20:21:27 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <K9QXVBYM>; Wed, 29 May 2002 19:21:26 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02B3F23E@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Dean Willis
	 <dean.willis@softarmor.com>
Cc: sip@ietf.org, rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com,
        ehenrikson@lucent.com, "Drage, Keith (Keith)"
	 <drage@lucent.com>
Subject: RE: [Sip] Poll: expert review of  draft-henrikson-sip-charging-in
	formation
Date: Wed, 29 May 2002 19:21:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Jonathan,

Thank you for the comments.  I am open to any alternative that solves the problem of correlating the dialogs at the S-CSCF.

Please confirm that I am understanding your proposal correctly.  

The problem we are trying to solve only pertains to the case of a B2BUA type of application server for 3GPP.  If an INVITE is sent from a S-CSCF to a B2BUA, which then sends a new INVITE back to the S-CSCF, I don't see how using just the Route information can be used to correlate the new INVITE with the old INVITE.  Each INVITE may have different To tag, From tag and Call-ID.  The (plain) Route header in the new INVITE may be common with dozens of other INVITEs that have followed this same path.  

I find the following definition for Route:

        Route        =  "Route" HCOLON route-param *(COMMA route-param)
        route-param  =  name-addr *( SEMI rr-param )
        rr-param     =  generic-param

Are you suggesting that there is some parameter placed in the 2nd Route header element inserted by the S-CSCF that it uses for the correlation?  If so, then is it ok to use a 3GPP specific parameter defined within 3GPP specifications (rr-param)?

If that is what is meant, then I can see where the S-CSCF could define a unique value to send with the 2nd Route header, e.g. ";correlate=2349873453", and we could require that 3GPP compliant B2BUA Application Servers return 2nd Route header as the topmost Route header to the S-CSCF .

Eric Henrikson

p.s. I presume you are referring to the P-Original-Dialog-ID draft and not the charging information draft.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, May 29, 2002 1:04 PM
To: Dean Willis
Cc: sip@ietf.org; rohan@cisco.com; brian.rosen@marconi.com;
jo@ipdialog.com; ehenrikson@lucent.com
Subject: Re: [Sip] Poll: expert review of
draft-henrikson-sip-charging-information


First off, I have to apologize for the lateness of these comments. Given
the scope of my comments, I should have raised them earlier. 

I have some serious concerns about this draft.

Most notably, I disagree entirely with the assessment that the problem
isn't entirely solved by loose routing. When the S-CSCF sends a request
to an application server, it ought to be inserting two loose routes -
one that points to the AS, and another that points back to itself,
containing whatever context is needed for the S-CSCF to do what it needs
to do from that point forward. The draft makes the following statement:

>  One may consider using the Route header as a mechanism to get the 
>     request sent back to the S-CSCF.  However, Route headers don't 
>     automatically transit an AS acting as a B2BUA. This could be 
>     overcome by using loose-routing and application logic in the B2BUA.  
>     But that is not the full problem to be solved. A strong correlation 
>     of dialogs is also needed for accounting purposes to treat the 
>     sequence of dialogs as a concatenated single dialog. A common 
>     identification tag needs to be carried in each related dialog so 
>     that the charging functions can associate all the dialogs. 

A smart B2BUA will not discard loose routes, particularly not one thats
used in 3gpp for this reason exactly. Thus, the principal motivation
given, being able to corelate incoming INVITEs from outgoing ones in a
spiral - is not correct. We explicitly designed the loose routing stuff
to enable exactly this kind of function (remember the Bjorkner service
route draft?).

The other argument that is given here - correlation of dialogs for
accounting purposes - makes no sense to me. The route header provides
the ability for the S-CSCF to completely correlate the incoming INVITE
to the one it sent out. It therefore has all the information it needs to
account for the calls and to know which applications are invoked. 

The last thing I want to do is specify two ways of doing the same thing.
Given that this kind of correlation is square in the sights of loose
routing, I am concerned about the overlap.

-Jonathan R.

Dean Willis wrote:
> 
> You may recall that we're doing an Expert Review of
> draft-henrikson-sip-charging-information.
> 
> If you have a strong opinion for, against, or supporting a need for
> further work, or any further suggestions for enhancement, please post
> them now.
> 
> --
> 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

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


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



From daemon@optimus.ietf.org  Thu May 30 10:26:56 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06763
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 10:26:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA03744
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 10:27:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00527;
	Thu, 30 May 2002 09:52:48 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00477
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 09:52:44 -0400 (EDT)
Received: from igate2.vodafone.co.uk (igate2.vodafone.co.uk [194.62.232.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05003
	for <sip@ietf.org>; Thu, 30 May 2002 09:52:19 -0400 (EDT)
From: duncan.mills@vf.vodafone.co.uk
Received: by igate2.vodafone.co.uk; (8.8.8/1.3/10May95) id OAA19187; Thu, 30 May 2002 14:51:55 +0100 (BST)
Received: from mimesweeper1.vfl.vodafone (mimesweeper1 [10.33.32.67])
	by mailguard1 (4.6.1.91) with ESMTP id 
	for <sip@ietf.org>; Thu, 30 May 2002 14:51:47 +0100
Received: from putney.vfl.vodafone (unverified) by mimesweeper1.vfl.vodafone
 (Content Technologies SMTPRS 2.0.15) with ESMTP id <B0016898912@mimesweeper1.vfl.vodafone>;
 Thu, 30 May 2002 14:51:46 +0100
Received: by putney.vfl.vodafone with Internet Mail Service (5.5.2650.21)
	id <L9A45M9B>; Thu, 30 May 2002 14:51:45 +0100
Message-Id: <DDC3D921FB67D211AAD100A0C9E58F530F42B768@hampstead.vfl.vodafone>
To: akristensen@dynamicsoft.com, sip@ietf.org
Subject: RE: [Sip] draft-mills-sip-access-network-info-02.txt grammer
Date: Thu, 30 May 2002 14:51:40 +0100
X-Mailer: Internet Mail Service (5.5.2650.21)
MIME-Version: 1.0 (Generated by Clearswift ES version 4.6.1.122)
Content-Type: text/plain;	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

Anders,

Yes, that was the intention.  I believe there is sufficient room for future
expansion (should we need it) with the 'extension-access-info' field.

Duncan


-----Original Message-----
From: Anders Kristensen [mailto:akristensen@dynamicsoft.com]
Sent: 29 May 2002 20:05
To: SIP
Subject: [Sip] draft-mills-sip-access-network-info-02.txt grammer


Nit: the grammar seems to allow only one access-info parameter per 
P-Access-Network-Info header. Is that intentional?

Anders


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 daemon@optimus.ietf.org  Thu May 30 10:30:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06894
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 10:30:00 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id KAA04095
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 10:30:24 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00934;
	Thu, 30 May 2002 09:57:36 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA00902
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 09:57:33 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05232
	for <sip@ietf.org>; Thu, 30 May 2002 09:57:09 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4UDunuF010039;
	Thu, 30 May 2002 06:56:49 -0700 (PDT)
Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ADA52282;
	Thu, 30 May 2002 06:57:11 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Juha Heinanen" <jh@lohi.eng.song.fi>,
        "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: "Cullen Jennings" <fluffy@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00
Date: Thu, 30 May 2002 07:02:08 -0700
Message-ID: <MFEJKLHKCMNFOPKPHMBPKEEFCCAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <15605.19484.700710.415050@rautu.eng.song.fi>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Would you feel better about this hint stuff if we put in that Spec(T) must
specify how the situation is handled when a node receiving a hint which is
not going to be honored. So Spec(T) would need to say that if you got a hint
and you were actually going to use a different AI in the trust domain, then
you must do one of a) just do it and not tell the user b) return an error to
the user c) unspecified.

I see difficulties in really deploying and this - at the UAC, it might be
hard to know AI the trust domain will use for UA - presumably I would need
to get it exactly right on the UA - if it is using both a sip and tel url do
I have to include both of them?

I feel there is a header where the UA gets to assert who it wants to be
known as - it's the From header. There is another header where the network
gets to assert information about who it thinks the user is - this is the
Asserted-Identity header. There is a header where the user gets to control
the scope of how widely this network information is distributed - that is
the Privacy header.

Cullen


-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Juha
Heinanen
Sent: Wednesday, May 29, 2002 2:46 PM
To: Peterson, Jon
Cc: Cullen Jennings; sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00


Peterson, Jon writes:

 > "Hint", for whatever reason, is the term that has stuck throughout this
 > discussion. There are meaningful cases in which a network would elect to
use
 > some identity other than that hinted by the user, so I don't feel this
term
 > is entirely inappropriate.

looks like my values differ from yours.  i as a service provider have to
respects the user's wish.  if there is many, i simply can't pick an
identity for a user on my own.  also, if the users wish conflicts with
his subscription, i must clear the call.

 > There is a concept, though one that is not discussed extensively in the
 > draft, that a user authenticates themselves in some fashion to the
network.
 > The Spec(T) example in the draft suggests SIP Digest authentication, if I
 > recall. The P-Asserted-Identity could be populated based on an identity
 > expressed in that authentication process, rather than a From header, in
the
 > absence of a hint (although admittedly in some networks the
authentication
 > will not supply a usable identity as such). This applies equally to cases
in
 > which the user has supplied an anonymous From header. This would seem to
 > provide a credible alternative to the MUST that you suggest below, one
that
 > I see no reason to rule out.

that doesn't work if the user has multiple sip identities.

 > The short-term identity work puts the network, not the user, firmly in
the
 > driver's seat.

sounds a very bellhead approach to me.  if the user claims to be someone
that conflicts with the idea of the network regarding who the user
should be, then the network should not make things up, but deny 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


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



From daemon@optimus.ietf.org  Thu May 30 12:41:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12460
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 12:41:46 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA19143
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 12:42:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17300;
	Thu, 30 May 2002 12:19:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17272
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 12:19:55 -0400 (EDT)
Received: from rautu.eng.song.fi (mail@dial-01-14.community.co.uk [195.72.167.142])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11510
	for <sip@ietf.org>; Thu, 30 May 2002 12:19:27 -0400 (EDT)
Received: from jh by rautu.eng.song.fi with local (Exim 3.12 #1 (Debian))
	id 17DB5L-00007Q-00; Thu, 30 May 2002 00:34:23 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15605.18783.943848.879871@rautu.eng.song.fi>
Date: Thu, 30 May 2002 00:34:23 +0300
To: Rohan Mahy <rohan@cisco.com>
Cc: sip@ietf.org
Subject: [Sip] P- headers vs. requirements in sip change process
In-Reply-To: <Pine.WNT.4.44.0205281912170.-474143@chorizo.rapidconvergence.com>
References: <Pine.WNT.4.44.0205281912170.-474143@chorizo.rapidconvergence.com>
X-Mailer: VM 7.00 under Emacs 21.1.1
From: Juha Heinanen <jh@lohi.eng.song.fi>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Rohan Mahy writes:

 >    3. No overlap with planned/chartered extensions
 >    4. Purely informational in nature

with regards to nai, i don't think the above two apply, since there is
clearly a generic need to augment sip with a nai style header when the
user has included anonymous from 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 daemon@optimus.ietf.org  Thu May 30 13:05:07 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13251
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 13:05:07 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id NAA20741
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 13:05:33 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18987;
	Thu, 30 May 2002 12:39:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18957
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 12:39:56 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12388
	for <sip@ietf.org>; Thu, 30 May 2002 12:39:30 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4UGdPHs015971;
	Thu, 30 May 2002 09:39:25 -0700 (PDT)
Received: from CJ650 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ADA55849;
	Thu, 30 May 2002 09:39:35 -0700 (PDT)
From: "Cullen Jennings" <fluffy@cisco.com>
To: "Elwell, John" <John.Elwell@siemenscomms.co.uk>, <sip@ietf.org>
Cc: "Fluffy" <fluffy@cisco.com>
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
Date: Thu, 30 May 2002 09:44:31 -0700
Message-ID: <MFEJKLHKCMNFOPKPHMBPGEEICCAA.fluffy@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BD@Beex50.siemenscomms.co.uk>
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


Yes, it should not be allowed. There can be at most one AI with a sip or
sips header and at most one AI with a tel. I agree the language is loose.
Any suggestion on what I should change this paragraph too?

What about:

   "The proxy MAY add a P-Asserted-Identity header field with either a
   single SIP URI or a single SIPS URI.  Likewise, the proxy MAY add a
   P-Asserted-Identity header field with a single tel URL. There can not be
   more that one of each of these so if there are existing
P-Asserted-Identity
   headers, they must be replaced."

I don't really like this either but it was the best I could do in 30
seconds - suggestions?

Thanks, Cullen


-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Elwell,
John
Sent: Thursday, May 30, 2002 5:31 AM
To: 'sip'
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity


Section 5, 3rd paragraph:
   "The proxy MAY add a P-Asserted-Identity header field with either a
   single SIP URI or a single SIPS URI.  Likewise, the proxy MAY add a
   P-Asserted-Identity header field with a single tel URL."

This seems to imply that a proxy can add a header even if there is already a
header of the type concerned. Presumably this should not be allowed.

--------------------------------------------------------------
John Elwell (john.elwell@siemens.com)
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.




> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 28 May 2002 22:32
> To: 'sip'
> Cc: brian.rosen@marconi.com; rohan@cisco.com; jo@ipdialog.com; 'Cullen
> Jennings'
> Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
>
>
>
> We need to do a quick working group last call on the
> "Asserted Identity"
> draft.
>
> Please submit comments to the list and draft editor IMMEDIATELY.
>
> Draft available from:
>
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-
identity-0
0.html
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-identity-0
0.txt

And soon to be in the internet-drafts archive.

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



From daemon@optimus.ietf.org  Thu May 30 14:11:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15958
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 14:11:42 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA25821
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:12:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23545;
	Thu, 30 May 2002 13:38:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23514
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 13:38:35 -0400 (EDT)
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14593
	for <sip@ietf.org>; Thu, 30 May 2002 13:38:08 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4UHbvI01297;
	Thu, 30 May 2002 12:37:57 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZVL1K>; Thu, 30 May 2002 12:37:52 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870381@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general
Date: Thu, 30 May 2002 12:37:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


Thanks for these extensive notes - the draft definitely needed a solid
reading. Most of these edits I'll accept as you've suggested; a few notes
below on interesting or controversial issues.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, May 29, 2002 12:29 PM
> To: Dean Willis
> Cc: 'sip'; rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com;
> Jon Peterson (jon.peterson@NeuStar.com)
> Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
> 
> 
> Comments:
> 
> > Withholding the identity of a user will, among other
> >    things, render the other parties in the dialog unable to send new SIP
> >    requests to the user outside of the context of the current dialog.
> 
> Thats not necessarily true; I can remain anonymous and even get a call
> back later on (for example, Reply-To: sip:user8222739@anonymous.net) -
> the key is that my identity is never revealed.
> 

I think anonymous callback is distinct from privacy as it is defined here.
Apparently, sip:userXYZ@anonymous.net is an address at which you can reached
-  even though it is a relatively opaque piece of data, I would still
consider it in this definition a form of identity, one best suited to
something like anonymous callback. The term 'personal information' is
sometimes used in this draft to refer to something other than 'identity' -
the identity sip:userXYZ@anonymous.net reveals no personal information.
Perhaps this is a distinction that could be drawn out a bit more.

[snip]
> 
> > The scope of these privacy requirements is solely the SIP protocol as
> >    it is described in [1].  The mechanisms at the disposal of user
> >    agents and proxy servers are restricted to those described in the SIP
> >    specification.  Also, the privacy properties of the headers listed in
> >    the core SIP specification alone, as opposed to headers defined by
> >    any existing or planned extension, are considered here.
> 
> I don't quite understand this paragraph. If a future extension defines a
> header that reveals identity information, shouldn't this draft cover
> requests for privacy of that information?
> 

I'll rephrase that a bit. My point was just that I don't happen to reference
and detail any existing SIP extensions in this draft. Obviously the draft
has its own extensibility mechanism to accomodate future extensions, and
even some recommendations for authors of extensions to SIP.

[snip]
> 
> > The following SIP headers, when generated by a user agent, can
> >    directly or indirectly reveal identity information about the
> >    originator of a message: From, Contact, Reply-To, Via, Call-Info,
> >    User-Agent, Organization, Subject, Call-ID, In-Reply-To
> 
[snip]
> Also, you have forgotten two very, very important ones - Authorization
> and Proxy-Authorization. In general, I think the draft needs discussion
> of these headers specifically. The user should only include such headers
> if it is willing to provide identity information for the realm provided
> in the challenge. Furthermore, the user may need to verify that the
> proxy is indeed part of the realm that they claim to be from before the
> user provides identity information to it. Right now, we have no real way
> to do that unless the proxy is the first hop proxy, in which case TLS
> can be used to ascertain the identity of the proxy that is providing the
> challenge before providing credentials. All of this needs to be
> discussed. The issue is similar to that of routing requests to privacy
> services.
> 

Some effort has been made in the recent privacy/identity work to split
privacy and identity concepts into separate drafts. The practices you
describe for providing identity information to a server that issues
challenges, I think, belong in the identity drafts, not here (there is some
text exactly to this effect in the second section of my longterm identity
draft, actually). For the most part, we've also tried to put concerns
related to authentication into the identity drafts, both of which
normatively depend on the privacy draft. I really don't want to duplicate
language and so forth, so I hope that the language in the Sec Cons of the
privacy draft is really all we need here.

There are, after all, other forms of authentication than SIP Digest, which
have parallel concerns, and I don't think we should open that can of worms
in the privacy draft.

> 
> >  Header field          where   proxy ACK BYE CAN INV OPT REG
> >    ___________________________________________________________
> >    Privacy                        amrd  o   o   o   o   o   -
> 
> I think privacy is still useful in a register message. It would be
> helpful when I want to register through my provider using an anonymizer
> service, which possibly obfuscates the Contact header. Interestingly,
> the privacy service couldn't obfuscate the From or To field, since these
> are needed by the registrar. Perhaps that is why Privacy is not allowed
> here? It makes me wonder if there is a need to specify privacy on a
> slighlty more granular level, allowing the user to request obfuscation
> of groups of headers (To/From in one group, Contact/Via/RR in 
> another).
> 

Yes, the To/From implication combined with obscuring of the Contact(s) is
one reason why Privacy isn't allowed here. Note that the levels of
granularity you suggest are already in the draft, I think, since the
procedures for 'header' level privacy (6.1) entail the obfuscation of
Contact/Via/RR, whereas only 'user' level privacy conceals the To/From. So
actually, I think it would be possible to only obscure contacts.

I guess this extension just isn't designed to keep identity information
private from registrars - the utility of that remains obscure to me after
some reflection on the matter. This is partly a question of when the privacy
service should be closer to the user (presumably one hop away) than a
registrar, when it should be farther away, and when the privacy service and
registrar should be colocated. Registering an anonymous Contact could be
meaningful when your privacy service is closer to you than your register. If
the two are conflated, or the registrar is closer than your privacy service,
there probably wouldn't be any need to register an anonymous Contact.
Although the draft mandates no architecture, I think it leans towards this
second scenario for providing privacy when you are the called party.

Given all that, though, I agree that this restriction can be removed -
there's no reason to forbid registering a Contact through a privacy service
that will provide privacy for these Contact addresses (granted that what
appears in the Contact after it passes through a privacy service is an
'anonymous callback' sort of contact address, rather than an unroutable URI
that expresses anonymity).

> >  critical: The user asserts that the privacy services requested for
> >       this message are critical, and that therefore, if these privacy
> >       services cannot be provided by the network, this request should be
> >       rejected.  Criticality cannot be managed appropriately for
> >       responses.
> 
> OK, I hate to dredge up old issues, and perhaps this was hashed out in
> the many privacy threads I didn't get to, but, it seems like the value
> of critical is going to neccessitate a Proxy-Require header. The draft
> makes no mention of the use of proxy-require or the protocol
> implications if the extension is not supported by proxies. The
> proxy-require can be removed once the services have been performed,
> which is a good thing.
> 

Proxy-Require would also make it difficult to have a privacy service reside
more than one hop away from a client.  But agreed that criticality is
severely hampered without something along these lines. This had been
discussed briefly (off the list, I think), but I don't think the discussion
ever arrived at any conclusion.

Throughout the draft the assumption is made that the user is aware of a
distinct privacy service in the network, with which they have some sort of
relationship, through which calls will be routed. Arguably, without that
relationship a privacy service is of no value (that is, not just any privacy
service will do - it must be one that is specifically known to the user for
reasons of accountability). In that sense, the draft makes the (possibly
dangerous) assumption that no in-band feature negotiation is necessary - the
user knows out-of-band that that the server in question supports privacy.
Would be a pity if they were wrong.

As we've discussed before, this taps somewhat into the whole service
discovery/composition problem, one that we know isn't going to be resolved
in the scope of this draft, anyway.

> >    It is RECOMMENDED that service providers couple the privacy service
> >    function with a local outbound proxy.  Users can thereby send their
> >    messages that request privacy through their usual outbound route.
> >    Users should not assume, however, that the administrative domain that
> >    is the destination of the request would be willing and able to
> >    perform the privacy service function on their behalf. 
> 
> How does the user know whether privacy services are supported? Do they
> need to try it with Proxy-Require to see if the request fails? 
> 

The text above is meant to suggest that users should know out-of-band that
their local administrative domain supports a privacy service function.

[snip]
> 
> > What a responding user agent can do, however, is ensure that the path
> >    by which requests reach them traverses their privacy service.  In
> >    some architectures, the privacy service function will be fulfilled by
> >    the same server to which requests for the local administrative domain
> >    are sent, and hence it will automatically be in the path of incoming
> >    requests.  However, if this is not the case, the user will have to
> >    ensure that requests are directed through a third-party privacy
> >    service.  The simplest way to accomplish this is to procure a
> >    'private' URI from the third-party service and to distribute this as
> >    an address-of-record.  The user would then register their normal
> >    address-of-record as a contact address with the third-party service.
> 
> Based on this, the third party privacy service would see the request
> before their actual provider. I can imagine there are also cases where
> the opposite makes more sense - the user registers their anonymous AOR
> as a contact address with their actual provider. TO me, this makes more
> sense. You want the privacy function closest to the user; in the case of
> responses, that means that you want it to be the first element that gets
> the response, which would motivate registering the anonymous AOR as a
> contact with the actual provider.

I think both approaches probably have their place. The approach I detail
above is more of a sort of anonymous callback' service; a user could
distribute a 'private' URI in the From field of requests they send. In this
case the privacy service effectively becomes the registrar of the user.

> 
> This also raises the question of whether a privacy service is a "hop"
> described by a URI in a route header, or is an identity, which would
> appear in the request URI and be translated. Clearly, the assumption
> above is the latter. Thats going to be true for some privacy services,
> but for things like session privacy, I would argue that these are hops,
> and they are ideally reached with URIs in route headers, not the
> request-URI.
> 

I think you are exposing that latent distinction in the draft between an
'anonymous callback' identity and a privacy service that acts on normal
identityies - that there are actually a couple of ways that a request could
potentially reach a privacy service. Pre-loaded routes are the most common
way, but anonymous callback identities are another way to reach a privacy
service. Again, agreed that this distinction should be formalized a bit.


> I don't understand why section 5 is a separate section. Since its about
> construct anonymous messages, it seems like it is naturally a subsection
> of 4.1. This relates to my meta-comment about the verbosity of the
> draft; it reads a bit too much like a dialog, and not quite enough like
> a protocol specification. Section 5 is really describing normative
> behavior for user agents, and belongs in the section which describes
> that.
> 

I suppose I felt that URI creation actually wasn't the exclusive
responsibility of user agents - privacy services also have some
responsibility for creating anonymous URIs. I really don't feel that
strongly about how the sections are arrayed.

Specmanship is a much more difficult art than protocol design. I think there
needs to be a prosody RFC, a Strunk & White of the IETF, so slow learners
like myself can get up to speed a little quicker.

> > This document defines a new SIP logical role called a "privacy
> >    service".  The privacy service role is instantiated by a network
> >    intermediary, frequently by entities that can act as SIP proxy
> >    servers.  The function of a privacy service is to supply privacy
> >    functions for SIP messages that cannot be provided by user agents
> >    themselves.
> 
> I think its worth noting that privacy services are described by URIs
> (see above comments on whether they are hop URIs or destination URIs)
> 
> > However, if the Privacy header value of
> >    'none' is specified in a message, privacy services MUST NOT perform
> >    any privacy function.
> 
> I have a feeling that the MUST NOT strength is going to be a problem for
> these folks that claim they have a regulatory requirement to provide
> privacy even when the user doesn't want it (or at least, I recall that
> this was the claim).
> 

I hope the existing wording will be sufficient - my conversations with some
of the parties raising these regulatory concerns have suggested that
networks are required to implement the user's preferences (that tends to be
the motivating government requirement). The trick is, there needs to be a
way for those preferences to be specified implicitly and administratively,
not just explicitly and in-band. We do provide a way to do that in the
draft.


> > When a privacy service performs one of the functions corresponding to
> >    a privacy level listed in the Privacy header, it SHOULD remove the
> >    corresponding priv-value from the Privacy header - otherwise, any
> >    other privacy service involved with routing this message might
> >    unnecessarily apply the same function, which in many cases would be
> >    undesirable.  When the last priv-value (not counting 'critical') has
> >    been removed from the Privacy header, the entire Privacy header MUST
> >    be removed from a message.
> 
> I am concerned about the complete removal of the privacy header. THe
> problem is that downstream elements may insert additional identification
> information into the request. I would propose that a new value for the
> header be defined, say "no-add", which tells elements that they don't
> need to modify any headers, but that they should not add any further
> identification information to a request. If the header value was present
> in a request, and is then performed by a proxy, the proxy changes that
> value to no-add.
> 

Agreed that parties downstream might add further information to the request
- but these entities might not even support the Privacy extension at all.
I'm not sure what we can really do to guard against this contingency. Maybe
this doesn't really come through in the text today (something I should fix),
but I've been envisioning that users should try not to route the request
through intermediaries that are likely to add personal information
subsequent to the privacy service (by choosing appropriate preloaded Route
header orders, perhaps). This argues a bit on the 'closeness' issue for
keeping your privacy service far away from you.

> >  When a privacy service alters the Contact header of a
> >    request, it MUST insert a Record-Route header pointing to itself so
> >    that it can restore the appropriate contact address as necessary.
> 
> Thats not true. The Contact header will presumably route to itself, so
> that an additional record-route is not necessary. 
> 

That would work too, and is probably more efficient -  I was envisioning
that the privacy service would add a Contact header with an anonymous URI
(i.e. one using the 'anonymous.invalid' hostname), and that therefore
Record-Routing was necessary to get the request back to the privacy service.
Of course if the Contact indicates the privacy service, that is sufficient.
I note that this makes the anonymous Contact registration story make a bit
more sense.

> > In a manner similar to Via hiding, a privacy service SHOULD also hide
> >    any Record-Route headers that have been added to a request before it
> >    reaches the privacy service.  Such Record-Route headers might also
> >    divulge information about the administrative domain of the client.
> >    Once Record-Route headers have been hidden, however, the privacy
> >    service MUST add appropriate Route headers to future requests as
> >    needed.
> 
> Given how easy it is to get this wrong, I would avise putting a bit more
> text in there about properly constructing the route and record-routes. 
> 

Agreed, it's potentially pretty complicated. My text above does ring a bit
of "magic happens".

> 
> > Therefore, any time that a privacy service needs to modify any
> >    dialog-matching headers for privacy reasons, it SHOULD act as a
> >    transparent back-to-back user agent
> 
> This was discussed on the list; the term transparent B2BUA is not
> defined in bis or in this document. You need to be more exact in your
> definitions.

I'd hate to be defining that common term in this document... but, agreed,
this section should be more explicit about the exact behavior required.

> > IANA Considerations
> > 
[snip]
> By the way, do we want to define a compact form?

Um... I don't know, really. Any other opinions about that?

> 
> THanks,
> Jonathan R.
> 
>

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



From daemon@optimus.ietf.org  Thu May 30 14:18:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16181
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 14:18:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA25988
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:17:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24191;
	Thu, 30 May 2002 13:51:08 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24159
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 13:51:05 -0400 (EDT)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15147
	for <sip@ietf.org>; Thu, 30 May 2002 13:50:39 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4UHoSc27425;
	Thu, 30 May 2002 13:50:28 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZVL2C>; Thu, 30 May 2002 12:50:23 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870382@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Ben Campbell'" <bcampbell@dynamicsoft.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general
Date: Thu, 30 May 2002 12:50:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


Thanks for the comments, Ben. We need 'em.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]
> Sent: Wednesday, May 29, 2002 3:10 PM
> To: Peterson, Jon; sip
> Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
> 
> 
> Some comments. My mail reader didn't want to cooperate on quotes--the 
> text between "" is from the draft.
> 
> Most of these are really nits
> 
> 
> "Note that there is a fine line between identity fraud and humor in some 
> cases. Many email clients by default render to the user only the 
> display-name of the sender of a message. It is easy to populate the 
> display-name in a way that many would consider abusive; it is best not 
> to select any display-name that may suggest an attempt to impersonate 
> someone else."
> 
> This section sounds like something that belongs in a bcp, not in a draft 
> that I assume is intended to become a normative RFC.

How about we move it to the Sec Cons - as far as I can make it, the Sec Cons
is a ghetto for well-meaning non-normative statements along these lines. 

> 
> "From the former [sip:jon.peterson@neustar.biz], the full name and 
> employer of the party in question can easily be gleaned. From the 
> latter, you learn nothing other than that the party desires anonymity. 
> In some cases, sufficient anonymity can be achieved by selecting an 
> oblique URI. Today, the SIP specification recommends a URI with 
> "anonymous" in the user portion of the From header."
> 
> Hmm, I fear someone might read this and believe too much, that is, that 
> they could really know the identity of the sender from a URL in a From 
> header. For example, _I_ could use that URL. If you glean something from 
> it, you would glean wrong. (Perhaps s/glean/guess would be 
> sufficient here.)

I can s/glean/guess.

> 
> "For these reasons, the hostname value 'anonymous.invalid' SHOULD be 
> used for anonymous URIs. The full recommended form of the From header 
> for anonymity is (note that this From header, like all others, MUST 
> contain a valid and unique 'tag=' parameter): "
> 
> Does this require reserving anonymous.invalid to never resolve to 
> something real? How would you enforce that? (Maybe a new TLD for 
> "invalid" :-)  )

Fortunately, RFC2606 beat us to it. Perhaps I should list this as a
reference.

> 
> "If the 'critical' privacy level is present in the Privacy header of a 
> request, then if the privacy service is incapable of performing all of 
> the levels of privacy specified in the Privacy header then it MUST 
> either fail the request, or it MUST forward the request to another 
> privacy service which can fulfill these functions (note that before 
> forwarding the request, the privacy service SHOULD complete a subset of 
> the functions if it can). "
> 
> This one scares me a little. It implies that, even if I have gone to a 
> great deal of trouble to directly talk to a privacy service (perhaps 
> over TLS) and specify "critical", it can still forward the request 
> without having performed privacy services. Doesn't this brings up the 
> whole transitity of trust and trust boundery issue that we keep getting 
> bogged down on?

I can see why this language would make you a little nervous. I think there
are perhaps a couple of good reasons to allow communities of privacy
services that can forward requests among one another (wiser authors in the
future might design onion routing schemes for SIP requests, or something).
Agreed there are some transitivity issues here - it is absolutely critical
that the user is related to the service that performs the privacy function.
Then again, if their privacy server has already performed some privacy
functions before forwarding the request (say, 'header' privacy), then a
second privacy service that performs additional functions ('session', say)
might not be in a position to even identity the originating user. There are
cases where this is useful, I think. I'm sensitive to your concerns, and I
think they merit some language, but I'm not sure what to add.

> 
> "Firstly, a request for header privacy entails that the server SHOULD 
> NOT add any of the following headers to the message: Call-Info, Server, 
> and Organization. All of these provide optional information that could 
> reveal facts about the user that has request anonymity. "
> 
> I would be happier if the situations that would allow the server to 
> insert one of those headers were enumerated. More of a "MUST NOT unless" 
> form. I tend to think it should be "MUST NOT unless it is impossible to 
> fulfill the SIP request without doing so."
> 

Are there any conditions in which the fulfillment of a request is predicated
on the population of any of those three headers? Maybe this is also related
to criticality - if a server must populate those headers, but cannot because
of a critical privacy condition, then it should most likely fail the
request.

> "Privacy services would be wise to authenticate users before providing a 
> privacy function. To downstream entities, the privacy service will be 
> the only responsible party to whom anonymous messages can be traced, and 
> in abuse cases the privacy service could be held accountable for the 
> actions of parties that it shelters. "
> 
> I'm not sure I agree with this. In some cases, _not_ authenticating 
> might be the only defence against sopoena(sp?). This paragraph falls 
> into the area of legal advice that should be given by lawers.
> 

Well, it's true that we shouldn't be trying to dispense legal advice as
such, but I feel the basic principle that is outlined here is worth
mentioning if we can eliminate any implication of professional counsel. I'll
see if I can't manage that.

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



From daemon@optimus.ietf.org  Thu May 30 14:18:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16182
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 14:18:20 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA26002
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:17:56 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24288;
	Thu, 30 May 2002 13:52:56 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA24253
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 13:52:53 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15233;
	Thu, 30 May 2002 13:52:26 -0400 (EDT)
Message-Id: <200205301752.NAA15233@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce: ;
cc: sip@ietf.org, sipping@ietf.org
Reply-to: iesg@ietf.org
Date: Thu, 30 May 2002 13:52:26 -0400
Subject: [Sip] Last Call: A Privacy Mechanism for the Session Initiation
 Protocol (SIP) to Proposed
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


The IESG has received a request from the Session Initiation Protocol
Working Group to consider A Privacy Mechanism for the Session Initiation
Protocol (SIP) <draft-ietf-sip-privacy-general-00.txt> for publication as
a Proposed Standard

The IESG will also consider publication of the following Internet-Drafts
for publication as Informational RFCs:

 o Extensions to the Session Initiation Protocol (SIP) for Asserted
   Identity
     <draft-ietf-sip-asserted-identity-00.txt>

 o Short term requirements for Network Asserted Identity
     <draft-ietf-sipping-nai-reqs-01.txt>

The IESG plans to make a decision in the next few weeks, and solicits
final
comments on this action.  Please send any comments to the iesg@ietf.org or
ietf@ietf.org mailing lists by June 13, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-general-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sip-asserted-identity-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-sipping-nai-reqs-01.txt


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



From daemon@optimus.ietf.org  Thu May 30 14:48:12 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17169
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 14:48:12 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id OAA27727
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 14:48:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26243;
	Thu, 30 May 2002 14:24:25 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26211
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 14:24:22 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16347;
	Thu, 30 May 2002 14:23:54 -0400 (EDT)
Message-Id: <200205301823.OAA16347@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>, Internet Architecture Board <iab@isi.edu>,
        sip@ietf.org
From: The IESG <iesg-secretary@ietf.org>
Date: Thu, 30 May 2002 14:23:54 -0400
Subject: [Sip] Document Action: SIP Extensions for Media Authorization to
 Informational
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org



The IESG has approved SIP Extensions for Media Authorization
<draft-ietf-sip-call-auth-06.txt> for publication as an Informational
RFC, but request that the title be changed to

   Private SIP Extensions for Media Authorization

This document is the product of the Session Initiation Protocol Working
Group.  The IESG contact persons are Allison Mankin and Scott Bradner.




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



From daemon@optimus.ietf.org  Thu May 30 17:20:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20215
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 17:20:57 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA05926
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 17:21:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03755;
	Thu, 30 May 2002 16:44:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03718
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 16:44:17 -0400 (EDT)
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19626
	for <sip@ietf.org>; Thu, 30 May 2002 16:43:51 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4UKhjI10436;
	Thu, 30 May 2002 15:43:45 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZVNGY>; Thu, 30 May 2002 15:43:40 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870387@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Elwell, John'" <John.Elwell@siemenscomms.co.uk>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general
Date: Thu, 30 May 2002 15:43:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


On the first issue, yes, the examples in sip-asserted-identity go against
this SHOULD in sip-privacy-general, with some good reasons. Perhaps those
reasons could stand to be motivated a bit in the identity draft - but I
don't think this is the wrong behavior, anyway.

On the second issue, the draft says if 'none' is present the privacy service
MUST NOT perform any privacy function. The draft also says (section 4.2):
"An intermediary MUST NOT modify the Privacy header in any way if the 'none'
priv-value is already specified." So I think it should be clear that Privacy
headers containing 'none' will not be removed.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Elwell, John [mailto:John.Elwell@siemenscomms.co.uk]
> Sent: Thursday, May 30, 2002 5:26 AM
> To: 'sip'
> Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general
> 
> 
>    "When a privacy service performs one of the functions corresponding to
>    a privacy level listed in the Privacy header, it SHOULD remove the
>    corresponding priv-value from the Privacy header - otherwise, any
>    other privacy service involved with routing this message might
>    unnecessarily apply the same function, which in many cases would be
>    undesirable."
> 
> This seems to be in contradiction with 
> draft-ietf-sip-asserted-identity,
> which show "Privacy: id" being maintained with the forwarded INVITE.
> 
>    "When the last priv-value (not counting 'critical') has
>    been removed from the Privacy header, the entire Privacy header MUST
>    be removed from a message."
> 
> Is this wise in the case of "None"?
> 
> --------------------------------------------------------------
> John Elwell (john.elwell@siemens.com)
> Siemens Communications Limited,
> Technology Drive, Beeston,
> Nottingham NG9 1LA, UK
> Tel: +44 115 943 4989   Fax: +44 115 943 4969
> --------------------------------------------------------------
> 	Internet communications are not secure and therefore Siemens
> Communications Limited does not accept legal responsibility for the
> contents of this message. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of Siemens
> Communications Limited unless otherwise specifically stated.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:dwillis@dynamicsoft.com]
> > Sent: 28 May 2002 22:32
> > To: 'sip'
> > Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com; Jon
> > Peterson (jon.peterson@NeuStar.com)
> > Subject: [Sip] WGLC for draft-ietf-sip-privacy-general
> > 
> > 
> > 
> > We need to do a quick review of the general privacy draft 
> > developed out
> > of our discussion in Las Vegas.
> > 
> > Please send any issues to the list and the editor IMMEDIATELY.
> > 
> > The draft is available from:
> > 
> > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g
> > eneral-00.
> > html
> > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-g
> eneral-00.
> txt
> And soon to be available from internet-drafts if not already . . .
> 
> 
> --
> 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



From daemon@optimus.ietf.org  Thu May 30 17:22:44 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20245
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 17:22:43 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA06011
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 17:23:09 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04282;
	Thu, 30 May 2002 16:59:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04257
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 16:59:54 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19878
	for <sip@ietf.org>; Thu, 30 May 2002 16:59:28 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4UKwW430043;
	Thu, 30 May 2002 15:58:32 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Elwell, John'" <John.Elwell@siemenscomms.co.uk>, "'sip'" <sip@ietf.org>
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
Date: Thu, 30 May 2002 15:57:43 -0500
Message-ID: <00d401c2081c$a4d08270$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5BD@Beex50.siemenscomms.co.uk>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit


John Elwell pondered:
> Section 5, 3rd paragraph:
>    "The proxy MAY add a P-Asserted-Identity header field with either a
>    single SIP URI or a single SIPS URI.  Likewise, the proxy MAY add a
>    P-Asserted-Identity header field with a single tel URL."
> 
> This seems to imply that a proxy can add a header even if 
> there is already a header of the type concerned. Presumably 
> this should not be allowed.

Why?

There might be some issue with multiple tel URLs and gateway
interworking, but asserting multiple identities seems like a very
reasonable thing from a SIP perspective.

If you're a PGP user, you may well have multiple identities associated
with one PGO key. There are practical reasons for doing this, and it
doesn't seem to cause any problems.

Different proxies or authentication servers might "know you" by
different identities and be able to assert those identities on your
behalf. It might also be reasonable to have multiple assertions for the
same identity, like multiple signers in PGP.

Signed,

dwillis@dynamicsoft.com
dean.willis@softarmor.com
dwillis@greycouncil.com
edean_willis@yahoo.com

Ad nasueatum . . .


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



From daemon@ns.ietf.org  Thu May 30 18:38:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21342
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 18:38:33 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA09717
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 18:38:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08490;
	Thu, 30 May 2002 18:14:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08459
	for <sip@ns.ietf.org>; Thu, 30 May 2002 18:14:56 -0400 (EDT)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21017
	for <sip@ietf.org>; Thu, 30 May 2002 18:14:30 -0400 (EDT)
Received: from chiimc01.il.neustar.com (stih650b-s1p2.va.neustar.com [209.173.53.65])
	by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g4UMEIc01090;
	Thu, 30 May 2002 18:14:18 -0400
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZV3R8>; Thu, 30 May 2002 17:14:12 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870389@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Dean Willis'" <dean.willis@softarmor.com>,
        "'Elwell, John'"
	 <John.Elwell@siemenscomms.co.uk>,
        "'sip'" <sip@ietf.org>
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
Date: Thu, 30 May 2002 17:14:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


I agree that asserting multiple identities is interesting. In the course of
the short-term work, we made a simple scope decision that multiple
identities (aside from one SIP[S] URI and one tel URL) is a long-term
problem. Obviously, it is pretty easy with the long-term approach to sign
multiple identity values in a single body, provide multiple bodies, and so
on.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Thursday, May 30, 2002 1:58 PM
> To: 'Elwell, John'; 'sip'
> Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
> 
> 
> 
> John Elwell pondered:
> > Section 5, 3rd paragraph:
> >    "The proxy MAY add a P-Asserted-Identity header field 
> with either a
> >    single SIP URI or a single SIPS URI.  Likewise, the 
> proxy MAY add a
> >    P-Asserted-Identity header field with a single tel URL."
> > 
> > This seems to imply that a proxy can add a header even if 
> > there is already a header of the type concerned. Presumably 
> > this should not be allowed.
> 
> Why?
> 
> There might be some issue with multiple tel URLs and gateway
> interworking, but asserting multiple identities seems like a very
> reasonable thing from a SIP perspective.
> 
> If you're a PGP user, you may well have multiple identities associated
> with one PGO key. There are practical reasons for doing this, and it
> doesn't seem to cause any problems.
> 
> Different proxies or authentication servers might "know you" by
> different identities and be able to assert those identities on your
> behalf. It might also be reasonable to have multiple 
> assertions for the
> same identity, like multiple signers in PGP.
> 
> Signed,
> 
> dwillis@dynamicsoft.com
> dean.willis@softarmor.com
> dwillis@greycouncil.com
> edean_willis@yahoo.com
> 
> Ad nasueatum . . .
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@ns.ietf.org  Thu May 30 18:45:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21441
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 18:45:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA09965
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 18:46:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08429;
	Thu, 30 May 2002 18:14:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08396
	for <sip@ns.ietf.org>; Thu, 30 May 2002 18:14:14 -0400 (EDT)
Received: from pine.neustar.com (pine.neustar.com [209.173.57.70])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21012
	for <sip@ietf.org>; Thu, 30 May 2002 18:13:49 -0400 (EDT)
Received: from chiimc01.il.neustar.com (chih650b-s3p2.il.neustar.com [209.173.57.65])
	by pine.neustar.com (8.11.0/8.11.0) with ESMTP id g4UMCuI15986;
	Thu, 30 May 2002 17:12:56 -0500
Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19)
	id <J25ZV3RV>; Thu, 30 May 2002 17:12:51 -0500
Message-ID: <70565611B164D511957A001083FCDD5601870388@va02.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Juha Heinanen'" <jh@lohi.eng.song.fi>, Rohan Mahy <rohan@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] P- headers vs. requirements in sip change process
Date: Thu, 30 May 2002 17:12:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org


While the purpose of the short-term asserted identity work overlaps with the
purpose of the long-term asserted identity work (both provide a means for
network intermediaries to ascertain and share identity information), I think
their delineation is fairly clear. The short-term work is inextricably tied
to the Trust Domain model and all that implies. Moreover, we are working on
defining (in a separate document) a means of gatewaying between networks
using the short-term approach and the Internet at large (i.e. the long-term
approach) which will throw the distinction into even starker relief. 

The purpose of this restriction in sipchange is, I think, to prevent P-
headers from becoming defacto standards that later chartered work cannot
replace. I would have to contend that the domain of applicability of the
short-term work is so limited that this risk is manageable.

I think the content of the NAI header is 'informational' - it is displayed
to the destination (or not, when privacy is required) as the identity of the
originator of the session. A header that is not 'informational' in this
sense would be, for example, the Via header, which is used directly in
routing message responses, and changes the behavior of nodes that handle it.
At least that's how I read the corresponding passage in sipchange; this is a
"header which merely provides additional information pertinent to a request
or a response".

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Juha Heinanen [mailto:jh@lohi.eng.song.fi]
> Sent: Wednesday, May 29, 2002 2:34 PM
> To: Rohan Mahy
> Cc: sip@ietf.org
> Subject: [Sip] P- headers vs. requirements in sip change process
> 
> 
> Rohan Mahy writes:
> 
>  >    3. No overlap with planned/chartered extensions
>  >    4. Purely informational in nature
> 
> with regards to nai, i don't think the above two apply, since there is
> clearly a generic need to augment sip with a nai style header when the
> user has included anonymous from 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
> 

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



From daemon@ns.ietf.org  Thu May 30 18:45:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21460
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 18:45:48 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA09979
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 18:46:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08647;
	Thu, 30 May 2002 18:18:03 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08616
	for <sip@ns.ietf.org>; Thu, 30 May 2002 18:17:59 -0400 (EDT)
Received: from magus.nostrum.com (root@magus.nostrum.com [66.119.225.66])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21079
	for <sip@ietf.org>; Thu, 30 May 2002 18:17:34 -0400 (EDT)
Received: from dynamicsoft.com (root@magus.nostrum.com [66.119.225.66])
	by magus.nostrum.com (8.11.0/8.11.0) with ESMTP id g4UMHcX88976;
	Thu, 30 May 2002 17:17:38 -0500 (CDT)
Message-ID: <3CF6A500.8080901@dynamicsoft.com>
Date: Thu, 30 May 2002 17:17:36 -0500
From: Ben Campbell <bcampbell@dynamicsoft.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>,
        Cullen Jennings
 <fluffy@cisco.com>,
        Mark Watson <mwatson@nortelnetworks.com>
CC: sip <sip@ietf.org>
X-Enigmail-Version: 0.49.5.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Comments on draft-ietf-sip-asserted-identity-00
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Some comments/questions:

> If a UA is part of the Trust Domain from which it received a message
>    containing a P-Asserted-Identity header field, then it can use the
>    value freely but it MUST ensure that it does not forward the
>    information to any element that is not part of the Trust Domain.
> 

Does this in any way depend on a request for privacy? Or do we place a 
stronger burden on a UAS than on a proxy for non-sharing of asserted 
identity?

(OK, just one question)

Thanks!

Ben.



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



From daemon@ns.ietf.org  Thu May 30 22:30:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24550
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 22:30:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id WAA19512
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 22:31:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17618;
	Thu, 30 May 2002 21:58:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17591
	for <sip@ns.ietf.org>; Thu, 30 May 2002 21:58:33 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24137
	for <sip@ietf.org>; Thu, 30 May 2002 21:58:05 -0400 (EDT)
Received: from [10.1.30.23] (rtp-vpn1-659.cisco.com [10.82.226.147])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4V1vlPI011486;
	Thu, 30 May 2002 18:57:48 -0700 (PDT)
Date: Thu, 30 May 2002 21:57:35 -0400
From: "David R. Oran" <oran@cisco.com>
To: Dean Willis <dean.willis@softarmor.com>,
        "'Christian Huitema'" <huitema@windows.microsoft.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
cc: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>, sip@ietf.org
Subject: RE: [Sip] Last Call: DHCPv6 Options for SIP Servers to Proposed
 Standard
Message-ID: <1082776.1022795855@[10.1.30.23]>
In-Reply-To: <011201c2069c$df496830$1d036e3f@TXDWILLIS2>
References:  <011201c2069c$df496830$1d036e3f@TXDWILLIS2>
X-Mailer: Mulberry/2.2.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

--On Tuesday, May 28, 2002 6:10 PM -0500 Dean Willis 
<dean.willis@softarmor.com> wrote:

>
> Christian said:
>> I don't think that the "firewall traversal" requirement
>> actually applies to hotel connections. The hotel connection
>> supposedly gives you a high speed Internet access, and they
>> often charge you good money for the service. The hotel has no
>> good reason to check whether you use TCP or UDP, or for that
>> matter IPSEC -- and since we are speaking of a DHCPv6 option,
>> we have to assume that we are using IPv6, and that there is
>> no NAT to go through. In these conditions, the only real
>> reason for the local proxy is a desire to control some
>> specific applications -- very possibly, make you pay phone
>> calls by the minute. As you say, this is silly, and I don't
>> see why we should tweak our standards encourage such silliness.
>
>
> Where are you finding hotels with broadband that don't require use of
> their NAT box and HTTP proxy? I've never seen a hotel with a truly open
> internet connection.
>
Uh, right here. I'm using one to send this message. For $9.95 a day you get 
a NAT'ed address and their HTP proxy. For $14.95 you get a public address 
and open access.

What's your point?
> -
> 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

-----------------------------------------------------------
David R. Oran                   Phone/Fax: +1 978 264 2048
Cisco Systems                   VoIP: +1 408 571 4576
7 Ladyslipper Lane              Email: oran@cisco.com
Acton, MA 01720


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



From daemon@ns.ietf.org  Thu May 30 23:15:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25363
	for <sip-archive@odin.ietf.org>; Thu, 30 May 2002 23:15:39 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id XAA21487
	for sip-archive@odin.ietf.org; Thu, 30 May 2002 23:16:04 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20142;
	Thu, 30 May 2002 22:45:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20115
	for <sip@ns.ietf.org>; Thu, 30 May 2002 22:45:43 -0400 (EDT)
Received: from mail.datang.com (38613.ddn.xaonline.com [61.185.215.108] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25107
	for <sip@ietf.org>; Thu, 30 May 2002 22:45:17 -0400 (EDT)
Received: from zhonghua (38625.ddn.xaonline.com [61.185.215.120] (may be forged))
	by mail.datang.com (8.11.0/8.11.0) with SMTP id g4V2rJj29057
	for <sip@ietf.org>; Fri, 31 May 2002 10:53:19 +0800
From: "zhong hua" <zhongh@163.net>
To: <sip@ietf.org>
Date: Fri, 31 May 2002 10:45:06 +0800
Message-ID: <BPENIKNNMKLGABJOFNJDGEJMCAAA.zhongh@163.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id WAA20116
Subject: [Sip] anycast
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

what is anycast type of service. 
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 daemon@ns.ietf.org  Fri May 31 02:24:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07093
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 02:24:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA06578
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 02:24:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05100;
	Fri, 31 May 2002 01:44:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA05069
	for <sip@ns.ietf.org>; Fri, 31 May 2002 01:44:06 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28078
	for <sip@ietf.org>; Fri, 31 May 2002 01:43:38 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4V5i3mG004402
	for <sip@ietf.org>; Fri, 31 May 2002 07:44:03 +0200 (MEST)
Received: from ericsson.com (3NJPI0013L1IJOG.lmf.ericsson.se [131.160.30.65])
	by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g4V5i3a9005688
	for <sip@ietf.org>; Fri, 31 May 2002 08:44:03 +0300 (EET DST)
Message-ID: <3CF70DA3.74A87943@ericsson.com>
Date: Fri, 31 May 2002 08:44:03 +0300
From: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
Organization: OY LM Ericsson AB
X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U)
X-Accept-Language: es,en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] draft-garcia-sip-associated-uri-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi:

I submitted version -02 of the P-Associated-URI header.
I have incorporated all the comments in the discussion. Note that is out of the scope of this draft to describe a proxy who is policing From headers and alike.

I believe the draft will be announced soon. In the meantime, you can fetch it from:
http://standards.ericsson.net/sip/drafts/draft-garcia-sip-associated-uri-02.txt

Other 2 P- headers draft revisions that were already announced are:
http://standards.ericsson.net/sip/drafts/draft-garcia-sip-visited-network-id-02.txt
http://standards.ericsson.net/sip/drafts/draft-garcia-sip-called-party-id-02.txt
These two include mainly clarifications and comments I got in the mailing list.

/Miguel
-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:Miguel.A.Garcia@ericsson.com     Phone:  +358 9 299 3553
mailto:Miguel.A.Garcia@piuha.net        Mobile: +358 40 5140002

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



From daemon@ns.ietf.org  Fri May 31 02:53:34 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07532
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 02:53:34 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id CAA08274
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 02:54:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07760;
	Fri, 31 May 2002 02:37:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA07728
	for <sip@ns.ietf.org>; Fri, 31 May 2002 02:37:27 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07289
	for <sip@ietf.org>; Fri, 31 May 2002 02:37:01 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 17Dg2P-0007Kk-00; Fri, 31 May 2002 09:37:25 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15607.6693.482999.227938@harjus.eng.song.fi>
Date: Fri, 31 May 2002 09:37:25 +0300
To: "Peterson, Jon" <jon.peterson@neustar.biz>
Cc: Rohan Mahy <rohan@cisco.com>, sip@ietf.org
Subject: RE: [Sip] P- headers vs. requirements in sip change process
In-Reply-To: <70565611B164D511957A001083FCDD5601870388@va02.va.neustar.com>
References: <70565611B164D511957A001083FCDD5601870388@va02.va.neustar.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Peterson, Jon writes:

 > I think the content of the NAI header is 'informational' - it is displayed
 > to the destination (or not, when privacy is required) as the identity of the
 > originator of the session. A header that is not 'informational' in this
 > sense would be, for example, the Via header, which is used directly in
 > routing message responses, and changes the behavior of nodes that handle it.
 > At least that's how I read the corresponding passage in sipchange; this is a
 > "header which merely provides additional information pertinent to a request
 > or a response".

when a request with nai header hits a sip/pstn gateway, for example, its
contents may very well effect how the message is handled or routed by
the gateway.

also, nai is and in fact MUST be used also within a single trust domain
if the user has specified anonymous from header and the request goes to
a sip/pstn gw..  so the nai header is not just some "nice to know"
thing, but an integral part of the sip specification.

finally we may even need a new error code to signal to the user that
inserts a nai header the case where the user inserted nai identity
doesn't match with the network.

-- 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 daemon@ns.ietf.org  Fri May 31 03:12:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07820
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 03:12:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA09550
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 03:13:13 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08363;
	Fri, 31 May 2002 02:55:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA08332
	for <sip@ns.ietf.org>; Fri, 31 May 2002 02:55:30 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07570
	for <sip@ietf.org>; Fri, 31 May 2002 02:55:04 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 17DgJt-0007LR-00; Fri, 31 May 2002 09:55:29 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15607.7777.699826.20294@harjus.eng.song.fi>
Date: Fri, 31 May 2002 09:55:29 +0300
To: "Cullen Jennings" <fluffy@cisco.com>
Cc: "Peterson, Jon" <jon.peterson@neustar.biz>, <sip@ietf.org>
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00
In-Reply-To: <MFEJKLHKCMNFOPKPHMBPKEEFCCAA.fluffy@cisco.com>
References: <15605.19484.700710.415050@rautu.eng.song.fi>
	<MFEJKLHKCMNFOPKPHMBPKEEFCCAA.fluffy@cisco.com>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Cullen Jennings writes:

 > I feel there is a header where the UA gets to assert who it wants to be
 > known as - it's the From header. 

yes, but if the user uses anonymous from header, the it MUST use nai
header for that purpose.

i don't know about Tspec(T).  nao should be part of basic sip and it
doesn't sound like a good idea to start to parameterize the basic
semantics of the protocol.  so my suggestion is that if the user
inserted nai doesn't match with networks opinion, the network MUST
reject the request with an error code.  the user then will know to
change the contents of the nai header, which is a very reasonable thing
to do.

-- 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 daemon@ns.ietf.org  Fri May 31 03:53:01 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08434
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 03:53:01 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id DAA11485
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 03:53:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09962;
	Fri, 31 May 2002 03:28:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA09933
	for <sip@ns.ietf.org>; Fri, 31 May 2002 03:28:32 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07982
	for <sip@ietf.org>; Fri, 31 May 2002 03:28:06 -0400 (EDT)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0GWY00G01SQ7PR@siemenscomms.co.uk> for sip@ietf.org;
 Fri, 31 May 2002 08:27:43 +0100 (BST)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0GWY00FFBSQ7L5@siemenscomms.co.uk>; Fri,
 31 May 2002 08:27:43 +0100 (BST)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <L6A2F9LT>; Fri, 31 May 2002 08:27:58 +0100
Content-return: allowed
Date: Fri, 31 May 2002 08:27:31 +0100
From: "Elwell, John" <John.Elwell@siemenscomms.co.uk>
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
To: "'Cullen Jennings'" <fluffy@cisco.com>
Cc: sip@ietf.org
Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C2@Beex50.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

Cullen,

What about:

"The proxy MAY add a P-Asserted-Identity header field with either a single
SIP URI or a single SIPS URI, provided there is not already a SIP URI or
SIPS URI present.  Likewise, the proxy MAY add a P-Asserted-Identity header
field with a single tel URL, provided there is not already a tel URL
present."

John

--------------------------------------------------------------
John Elwell (john.elwell@siemens.com)
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.




> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: 30 May 2002 17:45
> To: Elwell, John; sip@ietf.org
> Cc: Fluffy
> Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
> 
> 
> 
> Yes, it should not be allowed. There can be at most one AI 
> with a sip or
> sips header and at most one AI with a tel. I agree the 
> language is loose.
> Any suggestion on what I should change this paragraph too?
> 
> What about:
> 
>    "The proxy MAY add a P-Asserted-Identity header field with either a
>    single SIP URI or a single SIPS URI.  Likewise, the proxy MAY add a
>    P-Asserted-Identity header field with a single tel URL. 
> There can not be
>    more that one of each of these so if there are existing
> P-Asserted-Identity
>    headers, they must be replaced."
> 
> I don't really like this either but it was the best I could do in 30
> seconds - suggestions?
> 
> Thanks, Cullen
> 
> 
> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf 
> Of Elwell,
> John
> Sent: Thursday, May 30, 2002 5:31 AM
> To: 'sip'
> Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
> 
> 
> Section 5, 3rd paragraph:
>    "The proxy MAY add a P-Asserted-Identity header field with either a
>    single SIP URI or a single SIPS URI.  Likewise, the proxy MAY add a
>    P-Asserted-Identity header field with a single tel URL."
> 
> This seems to imply that a proxy can add a header even if 
> there is already a
> header of the type concerned. Presumably this should not be allowed.
> 
> --------------------------------------------------------------
> John Elwell (john.elwell@siemens.com)
> Siemens Communications Limited,
> Technology Drive, Beeston,
> Nottingham NG9 1LA, UK
> Tel: +44 115 943 4989   Fax: +44 115 943 4969
> --------------------------------------------------------------
> 	Internet communications are not secure and therefore Siemens
> Communications Limited does not accept legal responsibility for the
> contents of this message. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of Siemens
> Communications Limited unless otherwise specifically stated.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis@softarmor.com]
> > Sent: 28 May 2002 22:32
> > To: 'sip'
> > Cc: brian.rosen@marconi.com; rohan@cisco.com; 
> jo@ipdialog.com; 'Cullen
> > Jennings'
> > Subject: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
> >
> >
> >
> > We need to do a quick working group last call on the
> > "Asserted Identity"
> > draft.
> >
> > Please submit comments to the list and draft editor IMMEDIATELY.
> >
> > Draft available from:
> >
> > http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-
> identity-0
> 0.html
> http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-asserted-
identity-0
0.txt

And soon to be in the internet-drafts archive.

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



From daemon@ns.ietf.org  Fri May 31 04:03:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08609
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 04:03:38 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA12592
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 04:04:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10907;
	Fri, 31 May 2002 03:42:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA10878
	for <sip@ns.ietf.org>; Fri, 31 May 2002 03:42:29 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08175
	for <sip@ietf.org>; Fri, 31 May 2002 03:42:02 -0400 (EDT)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0GWY00H01TDI40@siemenscomms.co.uk> for sip@ietf.org;
 Fri, 31 May 2002 08:41:43 +0100 (BST)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0GWY00FNTTD9GH@siemenscomms.co.uk>; Fri,
 31 May 2002 08:41:33 +0100 (BST)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <L6A2F9Q7>; Fri, 31 May 2002 08:41:48 +0100
Content-return: allowed
Date: Fri, 31 May 2002 08:41:21 +0100
From: "Elwell, John" <John.Elwell@siemenscomms.co.uk>
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
To: "'Dean Willis'" <dean.willis@softarmor.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C3@Beex50.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

Dean,

My motivation for saying it should not be allowed was that it seemed to be
implied elsewhere in the document - I wanted clarification. However,
multiple identities of the same type might give a problem for gateways, as
you pointed out. I guess a gateway would just have to pick one, e.g., the
first.

Regards,

John

--------------------------------------------------------------
John Elwell (john.elwell@siemens.com)
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.




> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: 30 May 2002 21:58
> To: 'Elwell, John'; 'sip'
> Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
> 
> 
> 
> John Elwell pondered:
> > Section 5, 3rd paragraph:
> >    "The proxy MAY add a P-Asserted-Identity header field 
> with either a
> >    single SIP URI or a single SIPS URI.  Likewise, the 
> proxy MAY add a
> >    P-Asserted-Identity header field with a single tel URL."
> > 
> > This seems to imply that a proxy can add a header even if 
> > there is already a header of the type concerned. Presumably 
> > this should not be allowed.
> 
> Why?
> 
> There might be some issue with multiple tel URLs and gateway
> interworking, but asserting multiple identities seems like a very
> reasonable thing from a SIP perspective.
> 
> If you're a PGP user, you may well have multiple identities associated
> with one PGO key. There are practical reasons for doing this, and it
> doesn't seem to cause any problems.
> 
> Different proxies or authentication servers might "know you" by
> different identities and be able to assert those identities on your
> behalf. It might also be reasonable to have multiple 
> assertions for the
> same identity, like multiple signers in PGP.
> 
> Signed,
> 
> dwillis@dynamicsoft.com
> dean.willis@softarmor.com
> dwillis@greycouncil.com
> edean_willis@yahoo.com
> 
> Ad nasueatum . . .
> 

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



From daemon@ns.ietf.org  Fri May 31 04:21:24 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08919
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 04:21:23 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA13651
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 04:21:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11905;
	Fri, 31 May 2002 03:58:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA11874
	for <sip@ns.ietf.org>; Fri, 31 May 2002 03:58:39 -0400 (EDT)
Received: from lohi.eng.song.fi (lohi.eng.song.fi [195.10.149.18])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08498
	for <sip@ietf.org>; Fri, 31 May 2002 03:58:11 -0400 (EDT)
From: jh@lohi.eng.song.fi
Received: from harjus.eng.song.fi ([195.10.149.20])
	by lohi.eng.song.fi with esmtp (Exim 3.34 #1 (Debian))
	id 17DhIz-0007MY-00; Fri, 31 May 2002 10:58:37 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15607.11565.220136.731385@harjus.eng.song.fi>
Date: Fri, 31 May 2002 10:58:37 +0300
To: "Elwell, John" <John.Elwell@siemenscomms.co.uk>
Cc: "'Cullen Jennings'" <fluffy@cisco.com>, sip@ietf.org
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
In-Reply-To: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C2@Beex50.siemenscomms.co.uk>
References: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C2@Beex50.siemenscomms.co.uk>
X-Mailer: VM 7.01 under Emacs 21.1.1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Elwell, John writes:

 > "The proxy MAY add a P-Asserted-Identity header field with either a single
 > SIP URI or a single SIPS URI, provided there is not already a SIP URI or
 > SIPS URI present.  Likewise, the proxy MAY add a P-Asserted-Identity header
 > field with a single tel URL, provided there is not already a tel URL
 > present."

what about modifying an existing nai header? is that is not allowed then
the above text is fine with me, since it also forces the proxy to reject
the request if the user has inserted the nai and the network doesn't
like its contents.

-- 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 daemon@ns.ietf.org  Fri May 31 04:31:45 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09030
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 04:31:45 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id EAA14647
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 04:32:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13355;
	Fri, 31 May 2002 04:15:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA13260
	for <sip@ns.ietf.org>; Fri, 31 May 2002 04:15:46 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [194.129.217.115])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08860
	for <sip@ietf.org>; Fri, 31 May 2002 04:15:18 -0400 (EDT)
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk
 (PMDF V6.0-24 #45905) id <0GWY00H01UWZZC@siemenscomms.co.uk> for sip@ietf.org;
 Fri, 31 May 2002 09:14:59 +0100 (BST)
Received: from beex10.siemenscomms.co.uk ([137.223.246.252])
 by siemenscomms.co.uk (PMDF V6.0-24 #45905)
 with ESMTP id <0GWY00HAYUWYL2@siemenscomms.co.uk>; Fri,
 31 May 2002 09:14:59 +0100 (BST)
Received: by beex10.siemenscomms.co.uk with Internet Mail Service (5.5.2650.21)
	id <L6A2F0A7>; Fri, 31 May 2002 09:15:14 +0100
Content-return: allowed
Date: Fri, 31 May 2002 09:14:46 +0100
From: "Elwell, John" <John.Elwell@siemenscomms.co.uk>
Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
To: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "'Cullen Jennings'" <fluffy@cisco.com>
Cc: sip@ietf.org
Message-id: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C6@Beex50.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Content-Transfer-Encoding: 7BIT
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7BIT

I had assumed that any header that was to be removed would already have been
removed at this point. However, looking at the rest of the text again, this
is not clear. So how about:

"The proxy MAY add a P-Asserted-Identity header field with either a single
SIP URI or a single SIPS URI, provided there is not already a SIP URI or
SIPS URI present or replacing a SIP URI or SIPS URI from an untrusted
source.  Likewise, the proxy MAY add a P-Asserted-Identity header field with
a single tel URL, provided there is not already a tel URL present or
replacing a tel URL from an untrusted source."

John

--------------------------------------------------------------
John Elwell (john.elwell@siemens.com)
Siemens Communications Limited,
Technology Drive, Beeston,
Nottingham NG9 1LA, UK
Tel: +44 115 943 4989   Fax: +44 115 943 4969
--------------------------------------------------------------
	Internet communications are not secure and therefore Siemens
Communications Limited does not accept legal responsibility for the
contents of this message. Any views or opinions presented are solely
those of the author and do not necessarily represent those of Siemens
Communications Limited unless otherwise specifically stated.




> -----Original Message-----
> From: jh@lohi.eng.song.fi [mailto:jh@lohi.eng.song.fi]
> Sent: 31 May 2002 08:59
> To: Elwell, John
> Cc: 'Cullen Jennings'; sip@ietf.org
> Subject: RE: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
> 
> 
> Elwell, John writes:
> 
>  > "The proxy MAY add a P-Asserted-Identity header field with 
> either a single
>  > SIP URI or a single SIPS URI, provided there is not 
> already a SIP URI or
>  > SIPS URI present.  Likewise, the proxy MAY add a 
> P-Asserted-Identity header
>  > field with a single tel URL, provided there is not already 
> a tel URL
>  > present."
> 
> what about modifying an existing nai header? is that is not 
> allowed then
> the above text is fine with me, since it also forces the 
> proxy to reject
> the request if the user has inserted the nai and the network doesn't
> like its contents.
> 
> -- 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 daemon@optimus.ietf.org  Fri May 31 06:32:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10615
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 06:32:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id GAA21497
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 06:32:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20091;
	Fri, 31 May 2002 06:08:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20060
	for <sip@ns.ietf.org>; Fri, 31 May 2002 06:08:17 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10241
	for <sip@ietf.org>; Fri, 31 May 2002 06:07:51 -0400 (EDT)
Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4VA8F721835
	for <sip@ietf.org>; Fri, 31 May 2002 06:08:15 -0400 (EDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2653.19)
	id <KTF99XF9>; Fri, 31 May 2002 11:08:14 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB0051B5113@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Juha Heinanen <jh@lohi.eng.song.fi>, Cullen Jennings
	 <fluffy@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] draft-ietf-sip-asserted-identity-00
Date: Fri, 31 May 2002 11:08:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

The term "hint" was an attempt to get away from the impression that the user asserted the identity and the network "screened" it to use the much abused ISDN term.

My view is that the content of the asserted-identity is entirely a policy matter of the trusted network. How the trusted network therefore takes the "hint" is entirely up to the policy of the network. It must not be assumed by any reader that the  function is just screening, i.e. pass on the value or replace it by a new value.

For example, if the user provides a tel-url, and the trusted network knows of the relationship between that tel-url and a one of a number of sip-urls that it can assert, then it would be perfectly appropriate to assert the sip-url if that is what the network policy requires.

I have no problem including a network policy statement within the spec(t) as regards how the hint is handled, as to provide adequate hints the UA needs to have some knowledge of this, but I will object if anybody attempts to describe it as a "screening" function.

Keith



> -----Original Message-----
> From: Juha Heinanen [mailto:jh@lohi.eng.song.fi]
> Sent: 28 May 2002 08:23
> To: Cullen Jennings
> Cc: sip@ietf.org
> Subject: [Sip] draft-ietf-sip-asserted-identity-00
> 
> 
> once again:
> 
> the term "hint" is not a good one.  if user adds the a-i, then the
> network MUST respect it or reject the request.  the network MUST not
> override the a-i and pick one of the identities on its own.  for
> example, the user may have misspelled the its uri in the a-i.
> 
> also, the text should say that in case from is anonymous the user MUST
> insert the a-i header if it has multiple identities, because otherwise
> the network cannot know which identity the user wants to use.
> 
> finally, for backwards compatibility, if from is not anonymous and the
> user has multiple identities, then from uri can serve as the 
> purpose of
> a-i.
> 
> -- 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 daemon@optimus.ietf.org  Fri May 31 07:40:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12106
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 07:40:54 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA25603
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:41:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23850;
	Fri, 31 May 2002 07:21:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23819
	for <sip@optimus.ietf.org>; Fri, 31 May 2002 07:21:34 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11454;
	Fri, 31 May 2002 07:21:05 -0400 (EDT)
Message-Id: <200205311121.HAA11454@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 31 May 2002 07:21:05 -0400
Subject: [Sip] I-D ACTION:draft-ietf-sip-sec-agree-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: Security Mechanism Agreement for SIP Sessions
	Author(s)	: J. Arkko et al.
	Filename	: draft-ietf-sip-sec-agree-02.txt
	Pages		: 16
	Date		: 30-May-02
	
SIP has a number of security mechanisms. Some of them have been built
in to the SIP protocol, such as HTTP authentication or secure
attachments. These mechanisms have even alternative algorithms and
parameters. SIP does not currently provide any mechanism for
selecting which security mechanisms to use between two entities. In
particular, even if some mechanisms such as OPTIONS were used to make
this selection, the selection would be vulnerable against the
Bidding-Down attack. This document defines three header fields for
negotiating the security mechanisms within SIP between a SIP entity
and its next SIP hop. A SIP entity applying this mechanism must
always require some minimum security (i.e. integrity protection) from
all communicating parties in order to secure the negotiation, but the
negotiation can agree on which specific minimum security is used.

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

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

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

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 31 07:40:59 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12104
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 07:40:54 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA25604
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:41:21 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23900;
	Fri, 31 May 2002 07:21:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23863
	for <sip@optimus.ietf.org>; Fri, 31 May 2002 07:21:42 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11472;
	Fri, 31 May 2002 07:21:10 -0400 (EDT)
Message-Id: <200205311121.HAA11472@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 31 May 2002 07:21:10 -0400
Subject: [Sip] I-D ACTION:draft-willis-sip-path-08.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@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		: Session Initiation Protocol Extension for Registering 
                          Non-Adjacent Contacts
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-path-08.txt
	Pages		: 18
	Date		: 30-May-02
	
The REGISTER function is used in a SIP system primarily to associate
a temporary contact address with an address-of-record.  This contact
is generally in the form of a URI, such as Contact:
<sip:alice@pc33.atlanta.com> and is generally dynamic and associated
with the IP address or hostname of the SIP UA.  The problem is that
network topology may have one or more SIP proxies between the UA and
the registrar, such that any request travelling from the user's home
network to the registered UA must traverse these proxies.  The
REGISTER method does not give us a mechanism to discover and record
this sequence of proxies in the registrar for future use.  This
document defines an extension header field, 'Path' which provides
such a mechanism

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-willis-sip-path-08.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-willis-sip-path-08.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:	<20020530103536.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-willis-sip-path-08.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 31 07:41:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12142
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 07:41:15 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA25626
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:41:42 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23694;
	Fri, 31 May 2002 07:21:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23664
	for <sip@optimus.ietf.org>; Fri, 31 May 2002 07:21:09 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11380;
	Fri, 31 May 2002 07:20:41 -0400 (EDT)
Message-Id: <200205311120.HAA11380@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 31 May 2002 07:20:40 -0400
Subject: [Sip] I-D ACTION:draft-garcia-sip-associated-uri-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Private Session Initiation Protocol extension for 
                          Associated Uniform Resource Identifiers
	Author(s)	: M. Garcia
	Filename	: draft-garcia-sip-associated-uri-02.txt
	Pages		: 7
	Date		: 30-May-02
	
This memo describes a private extension to SIP [1] that allows a
registrar to return a set of associated URIs to a registered address-
of-record. We define the P-Associated-URI header field, used in the
200 OK response to a REGISTER request. The P-Associated-URI header
field transports the set of Associated URIs to the registered address-
of-record.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-garcia-sip-associated-uri-02.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 31 07:46:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12265
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 07:46:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id HAA25766
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 07:46:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23737;
	Fri, 31 May 2002 07:21:20 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23703
	for <sip@optimus.ietf.org>; Fri, 31 May 2002 07:21:16 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11398;
	Fri, 31 May 2002 07:20:45 -0400 (EDT)
Message-Id: <200205311120.HAA11398@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: sip@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Fri, 31 May 2002 07:20:44 -0400
Subject: [Sip] I-D ACTION:draft-willis-sip-scvrtdisco-06.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Session Initiation Protocol Extension Header Field for
                          Service Route Discovery in Private Networks
	Author(s)	: D. Willis, B. Hoeneisen
	Filename	: draft-willis-sip-scvrtdisco-06.txt
	Pages		: 16
	Date		: 30-May-02
	
This document proposes a private SIP extension header field used in
conjunction with responses to REGISTER requests to provide a
mechanism by which a registrar may inform a registering UA of a
service route that the UA may use to request outbound services from
the registrar's domain.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-willis-sip-scvrtdisco-06.txt

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

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

--OtherAccess--

--NextPart--



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



From daemon@optimus.ietf.org  Fri May 31 09:39:28 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16169
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 09:39:28 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id JAA04224
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 09:39:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29489;
	Fri, 31 May 2002 08:47:37 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07430
	for <sip@optimus.ietf.org>; Thu, 30 May 2002 17:55:58 -0400 (EDT)
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20720
	for <sip@ietf.org>; Thu, 30 May 2002 17:55:33 -0400 (EDT)
Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83])
	by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g4ULtR217150
	for <sip@ietf.org>; Thu, 30 May 2002 17:55:27 -0400 (EDT)
Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2653.19)
	id <L976795C>; Thu, 30 May 2002 16:55:26 -0500
Message-ID: <47AF9FA8BB0DD611A75C00A0C9AA883C02BD4FFB@il0015exch004u.ih.lucent.com>
From: "Henrikson, Eric H (Eric)" <ehenrikson@lucent.com>
To: Dean Willis <dean.willis@softarmor.com>, sip@ietf.org
Cc: rohan@cisco.com, brian.rosen@marconi.com, jo@ipdialog.com
Date: Thu, 30 May 2002 16:55:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Subject: [Sip] RE: Poll: expert review of draft-henrikson-sip-charging-informati
 on
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org

All,

Revision 3 of draft-henrikson-sip-charging-information has been submitted to 'Internet-Drafts@ietf.org' today.  

Revision 3 contains the following changes:
- additions to Applicability Statement for when the new charging headers don't apply
- clarifications to the Security Considerations
- fixing the examples to show IP addresses for the charging function addresses
- additional sections for acknowledgements and the full copyright statement

The new revision should appear on the IETF web site soon.  Please let me know if you have further comments or would like a copy of rev 3 prior to its appearence on the web site.

Thank you.
Eric Henrikson

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Friday, May 24, 2002 12:28 PM
To: sip@ietf.org
Cc: rohan@cisco.com; brian.rosen@marconi.com; jo@ipdialog.com;
ehenrikson@lucent.com
Subject: Poll: expert review of draft-henrikson-sip-charging-information



You may recall that we're doing an Expert Review of
draft-henrikson-sip-charging-information.

If you have a strong opinion for, against, or supporting a need for
further work, or any further suggestions for enhancement, please post
them now.

--
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 daemon@optimus.ietf.org  Fri May 31 11:42:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19895
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 11:42:24 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14594
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 11:42:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10724;
	Fri, 31 May 2002 10:58:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA10693
	for <sip@optimus.ietf.org>; Fri, 31 May 2002 10:58:49 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18671
	for <sip@ietf.org>; Fri, 31 May 2002 10:58:23 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id AFA85C2F0128; Fri, 31 May 2002 10:58:48 -0400
Message-ID: <00c001c208b2$e620b7e0$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>, <sip@ietf.org>
References: <200205291132.HAA10977@ietf.org> <3CF5424D.949B5346@dynamicsoft.com>
Subject: Re: [Sip] Re: I-D ACTION:draft-mills-sip-access-network-info-02.txt
Date: Fri, 31 May 2002 10:53:17 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
>
> The title needs to have the acronym SIP expanded.

I know this is a really minor point, but why does SIP need to be expanded in
the title? Most other I-Ds and RFCs (besides the base spec of course) use
the acronym of the protocol in their title. The problem we've had in the
past is that the title did not even include the acronym. Why not require the
expansion in the abstract?

cheers,
(-:bob


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



From daemon@optimus.ietf.org  Fri May 31 11:42:32 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19911
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 11:42:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id LAA14611
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 11:42:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12018;
	Fri, 31 May 2002 11:09:26 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA11992
	for <sip@optimus.ietf.org>; Fri, 31 May 2002 11:09:24 -0400 (EDT)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18948
	for <sip@ietf.org>; Fri, 31 May 2002 11:08:58 -0400 (EDT)
From: hisham.khartabil@nokia.com
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4VEFE901222
	for <sip@ietf.org>; Fri, 31 May 2002 17:15:14 +0300 (EET DST)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b33eff3a0ac158f2512d5@esvir05nok.ntc.nokia.com> for <sip@ietf.org>;
 Fri, 31 May 2002 17:16:27 +0300
Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 31 May 2002 17:16:27 +0300
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 31 May 2002 17:16:27 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Fri, 31 May 2002 17:16:26 +0300
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7779217@esebe019.NOE.Nokia.com>
Thread-Topic: comments on refer-04
Thread-Index: AcIIrcAhRc+Jb4ufR9mNrQJrotmnaw==
To: <sip@ietf.org>
X-OriginalArrivalTime: 31 May 2002 14:16:27.0203 (UTC) FILETIME=[C083E930:01C208AD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA11993
Subject: [Sip] comments on refer-04
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 8bit

Section 3.
"Refer-To is a request-header as defined by [1].  It may only appear
   in a REFER request"

Should that be a "MAY" or should it actually say "It only appears in a REFER request"?

Section 6.4
"Registrars and Redirect Servers SHOULD return a 603 to a REFER
   request, unless they are also playing some other SIP role."

I would think sending a 501 is more appropriate. This follows the default behaviour of UASs responding to unknown methods. 603 requires the registrar/redirect server to recognise the REFER.

How about "Registrars and Redirect servers do not require modifications to support the Refer method. A 501 response is returned by default if the UAS is RFC3216 compliant. If they are modified to support REFER, Registrars and Redirect Servers SHOULD return a 603 to a REFER request , unless they are also playing some other SIP role."

Section 7.
All Examples don't show the cookie in the branch-id of Via-header.

Regards,
Hisham

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



From daemon@optimus.ietf.org  Fri May 31 12:39:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21864
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 12:39:14 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id MAA20328
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 12:39:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15132;
	Fri, 31 May 2002 11:50:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15101
	for <sip@optimus.ietf.org>; Fri, 31 May 2002 11:50:07 -0400 (EDT)
Received: from crash.dfw.dynamicsoft.com ([63.110.3.64])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20125
	for <sip@ietf.org>; Fri, 31 May 2002 11:49:41 -0400 (EDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id g4VFrhV28374;
	Fri, 31 May 2002 10:53:44 -0500
Subject: Re: [Sip] comments on refer-04
From: Robert Sparks <rsparks@dynamicsoft.com>
To: hisham.khartabil@nokia.com
Cc: sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7779217@esebe019.NOE.Nokia.com>
References: <2038BCC78B1AD641891A0D1AE133DBB7779217@esebe019.NOE.Nokia.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 31 May 2002 10:45:34 -0500
Message-Id: <1022859935.1373.44.camel@dhcp150.dfw.dynamicsoft.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Thanks for the comments!

On Fri, 2002-05-31 at 09:16, hisham.khartabil@nokia.com wrote:
> Section 3.
> "Refer-To is a request-header as defined by [1].  It may only appear
>    in a REFER request"
> 
> Should that be a "MAY" or should it actually say "It only appears in a REFER request"?

the second

> 
> Section 6.4
> "Registrars and Redirect Servers SHOULD return a 603 to a REFER
>    request, unless they are also playing some other SIP role."
> 
> I would think sending a 501 is more appropriate. This follows the default behaviour of UASs responding to unknown methods. 603 requires the registrar/redirect server to recognise the REFER.
> 
> How about "Registrars and Redirect servers do not require modifications to support the Refer method. A 501 response is returned by default if the UAS is RFC3216 compliant. If they are modified to support REFER, Registrars and Redirect Servers SHOULD return a 603 to a REFER request , unless they are also playing some other SIP role."

I'll add a sentence capturing the 501 default behavior.

This 603 requirement, however, is old text and I don't think folks
have looked at it recently. I propose that it is wrong. A redirect
server is method agnostic and should treat REFER the way it treats
any other request (redirecting it if policy allows it). A registrar 
that knows what REFER is needs to reject the request but 603 is 
not the right code (603 implies that the REFER will fail 
_everywhere_). I believe 405 is the right code for this case.
I will make these changes unless I hear objections.

> 
> Section 7.
> All Examples don't show the cookie in the branch-id of Via-header.

Will fix

> 
> Regards,
> Hisham
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 daemon@ns.ietf.org  Fri May 31 16:17:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03636
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 16:17:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA02112
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:18:00 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00835;
	Fri, 31 May 2002 15:59:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00806
	for <sip@ns.ietf.org>; Fri, 31 May 2002 15:59:56 -0400 (EDT)
Received: from acmepacket.com (mail1.acmepacket.com [63.67.143.10])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02833
	for <sip@ietf.org>; Fri, 31 May 2002 15:59:27 -0400 (EDT)
Received: from BobP [63.67.143.2] by acmepacket.com
  (SMTPD32-7.05) id A638ABBE012A; Fri, 31 May 2002 15:59:52 -0400
Message-ID: <017c01c208dc$d0065b20$2300000a@acmepacket.com>
From: "Bob Penfield" <bpenfield@acmepacket.com>
To: "Peterson, Jon" <jon.peterson@neustar.biz>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
References: <70565611B164D511957A001083FCDD5601870381@va02.va.neustar.com>
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
Date: Fri, 31 May 2002 15:53:19 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

see comments below
----- Original Message -----
From: "Peterson, Jon" <jon.peterson@neustar.biz>
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
[snip]
> >
> > >  Header field          where   proxy ACK BYE CAN INV OPT REG
> > >    ___________________________________________________________
> > >    Privacy                        amrd  o   o   o   o   o   -
> >
> > I think privacy is still useful in a register message. It would be
> > helpful when I want to register through my provider using an anonymizer
> > service, which possibly obfuscates the Contact header. Interestingly,
> > the privacy service couldn't obfuscate the From or To field, since these
> > are needed by the registrar. Perhaps that is why Privacy is not allowed
> > here? It makes me wonder if there is a need to specify privacy on a
> > slighlty more granular level, allowing the user to request obfuscation
> > of groups of headers (To/From in one group, Contact/Via/RR in
> > another).
> >
>
> Yes, the To/From implication combined with obscuring of the Contact(s) is
> one reason why Privacy isn't allowed here. Note that the levels of
> granularity you suggest are already in the draft, I think, since the
> procedures for 'header' level privacy (6.1) entail the obfuscation of
> Contact/Via/RR, whereas only 'user' level privacy conceals the To/From. So
> actually, I think it would be possible to only obscure contacts.

As you say, there is only an implication of which headers the 'user' or
'header' levels apply to. Do we need an explicit list in the draft?

>
> I guess this extension just isn't designed to keep identity information
> private from registrars - the utility of that remains obscure to me after
> some reflection on the matter. This is partly a question of when the
privacy
> service should be closer to the user (presumably one hop away) than a
> registrar, when it should be farther away, and when the privacy service
and
> registrar should be colocated. Registering an anonymous Contact could be
> meaningful when your privacy service is closer to you than your register.
If
> the two are conflated, or the registrar is closer than your privacy
service,
> there probably wouldn't be any need to register an anonymous Contact.
> Although the draft mandates no architecture, I think it leans towards this
> second scenario for providing privacy when you are the called party.
>
> Given all that, though, I agree that this restriction can be removed -
> there's no reason to forbid registering a Contact through a privacy
service
> that will provide privacy for these Contact addresses (granted that what
> appears in the Contact after it passes through a privacy service is an
> 'anonymous callback' sort of contact address, rather than an unroutable
URI
> that expresses anonymity).

Although I agree that privacy is useful for REGISTER, it then becomes
critical that the REGISTER message be secured between the UA and the
registrar since it contains the mapping between the AOR and
anonymous-callback-URI.

> > >  critical: The user asserts that the privacy services requested for
> > >       this message are critical, and that therefore, if these privacy
> > >       services cannot be provided by the network, this request should
be
> > >       rejected.  Criticality cannot be managed appropriately for
> > >       responses.
> >
> > OK, I hate to dredge up old issues, and perhaps this was hashed out in
> > the many privacy threads I didn't get to, but, it seems like the value
> > of critical is going to neccessitate a Proxy-Require header. The draft
> > makes no mention of the use of proxy-require or the protocol
> > implications if the extension is not supported by proxies. The
> > proxy-require can be removed once the services have been performed,
> > which is a good thing.
> >
>
> Proxy-Require would also make it difficult to have a privacy service
reside
> more than one hop away from a client.  But agreed that criticality is
> severely hampered without something along these lines. This had been
> discussed briefly (off the list, I think), but I don't think the
discussion
> ever arrived at any conclusion.
>
> Throughout the draft the assumption is made that the user is aware of a
> distinct privacy service in the network, with which they have some sort of
> relationship, through which calls will be routed. Arguably, without that
> relationship a privacy service is of no value (that is, not just any
privacy
> service will do - it must be one that is specifically known to the user
for
> reasons of accountability). In that sense, the draft makes the (possibly
> dangerous) assumption that no in-band feature negotiation is necessary -
the
> user knows out-of-band that that the server in question supports privacy.
> Would be a pity if they were wrong.
>
> As we've discussed before, this taps somewhat into the whole service
> discovery/composition problem, one that we know isn't going to be resolved
> in the scope of this draft, anyway.
>
> > >    It is RECOMMENDED that service providers couple the privacy service
> > >    function with a local outbound proxy.  Users can thereby send their
> > >    messages that request privacy through their usual outbound route.
> > >    Users should not assume, however, that the administrative domain
that
> > >    is the destination of the request would be willing and able to
> > >    perform the privacy service function on their behalf.
> >
> > How does the user know whether privacy services are supported? Do they
> > need to try it with Proxy-Require to see if the request fails?
> >
>
> The text above is meant to suggest that users should know out-of-band that
> their local administrative domain supports a privacy service function.

I too am quite concerned about this. It seems adaquate to say the UA "just
knows" when we're talking about a P-Header with limited applicability, but
not necessarily for a general purpose protocol mechanism.

However, this mechanism would use a Require header, not a Proxy-Require.
There are very few headers mentioned in this draft that RFC 3261 allows a
proxy to modify or delete. I assert that performing any user, header or
session privacy functions in an intermediary turns the privacy service into
a B2BUA. If the UA is aware that is sending to a privacy service then it can
certainly be aware that it is sending to a B2BUA and include the tag in its
Require header.

[snip]
>
> > >  When a privacy service alters the Contact header of a
> > >    request, it MUST insert a Record-Route header pointing to itself so
> > >    that it can restore the appropriate contact address as necessary.
> >
> > Thats not true. The Contact header will presumably route to itself, so
> > that an additional record-route is not necessary.
> >
>
> That would work too, and is probably more efficient -  I was envisioning
> that the privacy service would add a Contact header with an anonymous URI
> (i.e. one using the 'anonymous.invalid' hostname), and that therefore
> Record-Routing was necessary to get the request back to the privacy
service.
> Of course if the Contact indicates the privacy service, that is
sufficient.
> I note that this makes the anonymous Contact registration story make a bit
> more sense.

I agree that just the Contact is more efficient, but will that be the only
method allowed?

And one more thing, in section 6 it says "Privacy services MUST implement
the 'none' and 'critical' privacy levels". I just thought it was weird that
a privacy service that had the minimum required implementation would not
actually perform any privacy function.

cheers,
(-:bob


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



From daemon@ns.ietf.org  Fri May 31 16:32:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03970
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 16:32:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA03387
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:32:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01689;
	Fri, 31 May 2002 16:09:38 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01660
	for <sip@ns.ietf.org>; Fri, 31 May 2002 16:09:33 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03477
	for <sip@ietf.org>; Fri, 31 May 2002 16:09:04 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKAbYH028738;
	Fri, 31 May 2002 16:10:37 -0400 (EDT)
Message-ID: <3CF7D859.367EB56@dynamicsoft.com>
Date: Fri, 31 May 2002 16:08:57 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
References: <70565611B164D511957A001083FCDD5601870381@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



"Peterson, Jon" wrote:
> 

> > Thats not necessarily true; I can remain anonymous and even get a call
> > back later on (for example, Reply-To: sip:user8222739@anonymous.net) -
> > the key is that my identity is never revealed.
> >
> 
> I think anonymous callback is distinct from privacy as it is defined
> here.
> Apparently, sip:userXYZ@anonymous.net is an address at which you can
> reached
> -  even though it is a relatively opaque piece of data, I would still
> consider it in this definition a form of identity, one best suited to
> something like anonymous callback. The term 'personal information' is
> sometimes used in this draft to refer to something other than 'identity'
> -
> the identity sip:userXYZ@anonymous.net reveals no personal information.
> Perhaps this is a distinction that could be drawn out a bit more.

I'm confused as to whether you are agreeing or disagreeing with me....


> > > The scope of these privacy requirements is solely the SIP protocol
> as
> > >    it is described in [1].  The mechanisms at the disposal of user
> > >    agents and proxy servers are restricted to those described in the
> SIP
> > >    specification.  Also, the privacy properties of the headers
> listed in
> > >    the core SIP specification alone, as opposed to headers defined
> by
> > >    any existing or planned extension, are considered here.
> >
> > I don't quite understand this paragraph. If a future extension defines
> a
> > header that reveals identity information, shouldn't this draft cover
> > requests for privacy of that information?
> >
> 
> I'll rephrase that a bit. My point was just that I don't happen to
> reference
> and detail any existing SIP extensions in this draft. Obviously the
> draft
> has its own extensibility mechanism to accomodate future extensions, and
> even some recommendations for authors of extensions to SIP.

Right - but what I mean is, if a future extension to SIP defines some
new form of identity, this specification would apply to help ensure
privacy of that information, no?

> > Also, you have forgotten two very, very important ones - Authorization
> > and Proxy-Authorization. In general, I think the draft needs
> discussion
> > of these headers specifically. The user should only include such
> headers
> > if it is willing to provide identity information for the realm
> provided
> > in the challenge. Furthermore, the user may need to verify that the
> > proxy is indeed part of the realm that they claim to be from before
> the
> > user provides identity information to it. Right now, we have no real
> way
> > to do that unless the proxy is the first hop proxy, in which case TLS
> > can be used to ascertain the identity of the proxy that is providing
> the
> > challenge before providing credentials. All of this needs to be
> > discussed. The issue is similar to that of routing requests to privacy
> > services.
> >
> 
> Some effort has been made in the recent privacy/identity work to split
> privacy and identity concepts into separate drafts. The practices you
> describe for providing identity information to a server that issues
> challenges, I think, belong in the identity drafts, not here (there is
> some
> text exactly to this effect in the second section of my longterm
> identity
> draft, actually). For the most part, we've also tried to put concerns
> related to authentication into the identity drafts, both of which
> normatively depend on the privacy draft. I really don't want to
> duplicate
> language and so forth, so I hope that the language in the Sec Cons of
> the
> privacy draft is really all we need here.

There are privacy concerns with digest which are important to mention.
Specifically, a UA that wants to know who I am might issue a 401, and
fake the realm for my domain. I provide my identity in an Authorization
header, and this information is then provided to the UAS. The problem is
that the existing digest mechanism has a flaw regarding privacy, in that
there is no assurance that the entity requesting credentials for the
realm properly represents the realm, unless you are connected to them
through TLS. Thus, I think it is important to mention this problem here.


> 
> There are, after all, other forms of authentication than SIP Digest,
> which
> have parallel concerns, and I don't think we should open that can of
> worms
> in the privacy draft.

The problem above is specific to digest. It doesn't exist for other
forms of authentication (for example, entering a pin into an IVR
system), since there I can verify the identity of the system because I
dialed the number to access it, and *presumably* pstn routing will
ensure that the call reaches the proper system.


> > I think privacy is still useful in a register message. It would be
> > helpful when I want to register through my provider using an
> anonymizer
> > service, which possibly obfuscates the Contact header. Interestingly,
> > the privacy service couldn't obfuscate the From or To field, since
> these
> > are needed by the registrar. Perhaps that is why Privacy is not
> allowed
> > here? It makes me wonder if there is a need to specify privacy on a
> > slighlty more granular level, allowing the user to request obfuscation
> > of groups of headers (To/From in one group, Contact/Via/RR in
> > another).
> >
> 
> Yes, the To/From implication combined with obscuring of the Contact(s)
> is
> one reason why Privacy isn't allowed here. Note that the levels of
> granularity you suggest are already in the draft, I think, since the
> procedures for 'header' level privacy (6.1) entail the obfuscation of
> Contact/Via/RR, whereas only 'user' level privacy conceals the To/From.
> So
> actually, I think it would be possible to only obscure contacts.

OK, I missed that.

> 
> I guess this extension just isn't designed to keep identity information
> private from registrars - the utility of that remains obscure to me
> after
> some reflection on the matter. This is partly a question of when the
> privacy
> service should be closer to the user (presumably one hop away) than a
> registrar, when it should be farther away, and when the privacy service
> and
> registrar should be colocated. Registering an anonymous Contact could be
> meaningful when your privacy service is closer to you than your
> register. If
> the two are conflated, or the registrar is closer than your privacy
> service,
> there probably wouldn't be any need to register an anonymous Contact.
> Although the draft mandates no architecture, I think it leans towards
> this
> second scenario for providing privacy when you are the called party.
> 
> Given all that, though, I agree that this restriction can be removed -
> there's no reason to forbid registering a Contact through a privacy
> service
> that will provide privacy for these Contact addresses (granted that what
> appears in the Contact after it passes through a privacy service is an
> 'anonymous callback' sort of contact address, rather than an unroutable
> URI
> that expresses anonymity).

True; this differing requirement may be sufficient to say that REGISTER
security really is something different, and would necessitate a separate
tag for it. So, I'm changing my mind here.


> 
> > >  critical: The user asserts that the privacy services requested for
> > >       this message are critical, and that therefore, if these
> privacy
> > >       services cannot be provided by the network, this request
> should be
> > >       rejected.  Criticality cannot be managed appropriately for
> > >       responses.
> >
> > OK, I hate to dredge up old issues, and perhaps this was hashed out in
> > the many privacy threads I didn't get to, but, it seems like the value
> > of critical is going to neccessitate a Proxy-Require header. The draft
> > makes no mention of the use of proxy-require or the protocol
> > implications if the extension is not supported by proxies. The
> > proxy-require can be removed once the services have been performed,
> > which is a good thing.
> >
> 
> Proxy-Require would also make it difficult to have a privacy service
> reside
> more than one hop away from a client.

I thought you had argued that it more or less HAS to be one hop away in
order to properly authenticate it....

>  But agreed that criticality is
> severely hampered without something along these lines. This had been
> discussed briefly (off the list, I think), but I don't think the
> discussion
> ever arrived at any conclusion.
> 
> Throughout the draft the assumption is made that the user is aware of a
> distinct privacy service in the network, with which they have some sort
> of
> relationship, through which calls will be routed. Arguably, without that
> relationship a privacy service is of no value (that is, not just any
> privacy
> service will do - it must be one that is specifically known to the user
> for
> reasons of accountability). In that sense, the draft makes the (possibly
> dangerous) assumption that no in-band feature negotiation is necessary -
> the
> user knows out-of-band that that the server in question supports
> privacy.
> Would be a pity if they were wrong.

Big pity.

> 
> As we've discussed before, this taps somewhat into the whole service
> discovery/composition problem, one that we know isn't going to be
> resolved
> in the scope of this draft, anyway.

I don't think we need to boil the ocean here. If the common case is the
one where the privacy service is one hop away, and the user wants
assurance that its really running there, Proxy-Require provides an easy
way to determine that with no loss of functionality (it should strip the
proxy-require). There are clear problems if its multiple hops away, and
so perhaps its not used in that case, or perhaps it is, but at least its
defined and available in order to get a high degree of assurance.


> > Based on this, the third party privacy service would see the request
> > before their actual provider. I can imagine there are also cases where
> > the opposite makes more sense - the user registers their anonymous AOR
> > as a contact address with their actual provider. TO me, this makes
> more
> > sense. You want the privacy function closest to the user; in the case
> of
> > responses, that means that you want it to be the first element that
> gets
> > the response, which would motivate registering the anonymous AOR as a
> > contact with the actual provider.
> 
> I think both approaches probably have their place. The approach I detail
> above is more of a sort of anonymous callback' service; a user could
> distribute a 'private' URI in the From field of requests they send. In
> this
> case the privacy service effectively becomes the registrar of the user.

OK, so can the other case get documented here as well?


> > I don't understand why section 5 is a separate section. Since its
> about
> > construct anonymous messages, it seems like it is naturally a
> subsection
> > of 4.1. This relates to my meta-comment about the verbosity of the
> > draft; it reads a bit too much like a dialog, and not quite enough
> like
> > a protocol specification. Section 5 is really describing normative
> > behavior for user agents, and belongs in the section which describes
> > that.
> >
> 
> I suppose I felt that URI creation actually wasn't the exclusive
> responsibility of user agents - privacy services also have some
> responsibility for creating anonymous URIs. I really don't feel that
> strongly about how the sections are arrayed.

We ran into this issue a few times with bis, and decided to place the
text within the context that first needed it, and then back-reference it
from the other place. 


> > > When a privacy service performs one of the functions corresponding
> to
> > >    a privacy level listed in the Privacy header, it SHOULD remove
> the
> > >    corresponding priv-value from the Privacy header - otherwise, any
> > >    other privacy service involved with routing this message might
> > >    unnecessarily apply the same function, which in many cases would
> be
> > >    undesirable.  When the last priv-value (not counting 'critical')
> has
> > >    been removed from the Privacy header, the entire Privacy header
> MUST
> > >    be removed from a message.
> >
> > I am concerned about the complete removal of the privacy header. THe
> > problem is that downstream elements may insert additional
> identification
> > information into the request. I would propose that a new value for the
> > header be defined, say "no-add", which tells elements that they don't
> > need to modify any headers, but that they should not add any further
> > identification information to a request. If the header value was
> present
> > in a request, and is then performed by a proxy, the proxy changes that
> > value to no-add.
> >
> 
> Agreed that parties downstream might add further information to the
> request
> - but these entities might not even support the Privacy extension at
> all.

Yup. Bad. 

> I'm not sure what we can really do to guard against this contingency.

Well, if you had the proxy-require tag, you could have a privacy tag
which instructed the last service to not strip proxy-require. This
provides insanely high degrees of certainty, at a cost of interop. If
the proxy-require is stripped, having the privacy tag still there at
least helps in those proxies which DO understand this extension, so its
still better than nothing. If, as we hope, this draft gets widely
implemented, and every proxy supports it, you would hamper the ability
to offer privacy functions to future extensions that might have proxies
inserting information. As such, I feel quite strongly that some kind of
privacy tag needs to get propagated all the way.

> Maybe
> this doesn't really come through in the text today (something I should
> fix),
> but I've been envisioning that users should try not to route the request
> through intermediaries that are likely to add personal information
> subsequent to the privacy service (by choosing appropriate preloaded
> Route
> header orders, perhaps). This argues a bit on the 'closeness' issue for
> keeping your privacy service far away from you.

Well, I don't know in general how the user would know ahead of times
what route headers to use in order to avoid additional intermediaries...

> >
> > > Therefore, any time that a privacy service needs to modify any
> > >    dialog-matching headers for privacy reasons, it SHOULD act as a
> > >    transparent back-to-back user agent
> >
> > This was discussed on the list; the term transparent B2BUA is not
> > defined in bis or in this document. You need to be more exact in your
> > definitions.
> 
> I'd hate to be defining that common term in this document... but,
> agreed,
> this section should be more explicit about the exact behavior required.
> 
> > > IANA Considerations
> > >
> [snip]
> > By the way, do we want to define a compact form?
> 
> Um... I don't know, really. Any other opinions about that?

I always have mixed feelings on compact form; arguably sigcomp makes it
moot, but since we are approaching the mtu in many inter-proxy
messages...

-Jonathan R.

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

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



From daemon@ns.ietf.org  Fri May 31 16:32:06 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03969
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 16:32:05 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA03378
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:32:30 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01625;
	Fri, 31 May 2002 16:08:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01594
	for <sip@ns.ietf.org>; Fri, 31 May 2002 16:08:50 -0400 (EDT)
Received: from p2.piuha.net (p2.piuha.net [131.160.192.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03467
	for <sip@ietf.org>; Fri, 31 May 2002 16:08:22 -0400 (EDT)
Received: by p2.piuha.net (Postfix, from userid 962)
	id 692A46A906; Fri, 31 May 2002 23:08:48 +0300 (EEST)
Received: from piuha.net (p4.piuha.net [131.160.192.4])
	by p2.piuha.net (Postfix) with ESMTP id 801936A905
	for <sip@ietf.org>; Fri, 31 May 2002 23:08:46 +0300 (EEST)
Message-ID: <3CF7D893.9010702@piuha.net>
Date: Fri, 31 May 2002 23:09:55 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Organization: None
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014
X-Accept-Language: en-us
MIME-Version: 1.0
To: sip <sip@ietf.org>
References: <933FADF5E673D411B8A30002A5608A0E03A63273@zrc2c012.us.nortel.com> <3CE0B7C0.C4A1F003@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.6 required=7.0 tests=TO_LOCALPART_EQ_REAL version=2.20
Content-Transfer-Encoding: 7bit
Subject: [Sip] RTP, SIP, UDP, and IPv6 NUD
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

I'm working on an informational document (draft-ietf-ipv6-cellular-host-02.txt)
that discusses some issues related to IPv6 implementation on mobile
terminals.

IPv6 has a function for Neighbour Unreachability Detection (NUD, RFC 2461).
The purpose of this function is to ensure that the nearest neighbour,
typically the router, is up and running. This check is normally done at
the IP layer, by sending a Neighbour Solicitation message and getting back
a Neighbour Advertisement message.

However, these messages are sometimes unnecessary if some upper layer
already knows that we have connectivity. RFC 2461 specifies that the
reception of a TCP acknowledgement for something that we have sent
recently shows that we have connectivity to the peer, and consequently,
to the router. Note that it isn't enough to see that we are *receiving*
packets, we need to know if the packets we *sent* are getting through.
Note also that any upper-layer advise to IPv6 is purely a local
optimization and optional.

Unfortunately, the TCP ACK scheme doesn't work with UDP, and this might
lead to sending some unnecessary NS/NA messages when SIP and RTP traffic is
running over UDP. As bandwidth usage on cellular environments is pretty
critical, we'd like to do something about it. I've been asked to
describe whether some typical cellular host applications can provide
such feedback. And here's why I come to you, given that SIP and RTP-based
IP traffic is a one of the major applications.

My first question is if RTCP can provide the information. Does this
work. (Yeah, I know its the wrong group but I'm subscribed here
and I'm sure you know the answer.)

       When UDP is used for transporting RTP, the RTCP
       protocol feedback should be used as a basis for
       the reachability confirmation. If an RTCP
       packet is received with a reception report block
       indicating some packets have gone through, then packets
       are reaching the peer. If they have reached the
       peer, they have also reached the neighbour.

The second question is if SIP can provide the information. Does this
work:

       When UDP is used for transporting SIP, responses to
       SIP requests should be used as the confirmation that
       packets sent to the peer are reaching it. When the
       host is acting as the server side SIP node, such
       confirmation is generally not available. However,
       a host may interprete the receipt of a SIP ACK request
       as confirmation that the previously sent response
       to a SIP INVITE request has reached the peer.

Thanks,

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 daemon@ns.ietf.org  Fri May 31 16:37:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04127
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 16:37:36 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA03717
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:38:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01938;
	Fri, 31 May 2002 16:14:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01907
	for <sip@ns.ietf.org>; Fri, 31 May 2002 16:14:25 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03569
	for <sip@ietf.org>; Fri, 31 May 2002 16:13:56 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKFTYH028742;
	Fri, 31 May 2002 16:15:29 -0400 (EDT)
Message-ID: <3CF7D980.6D30361D@dynamicsoft.com>
Date: Fri, 31 May 2002 16:13:52 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: "'Ben Campbell'" <bcampbell@dynamicsoft.com>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
References: <70565611B164D511957A001083FCDD5601870382@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



"Peterson, Jon" wrote:
> 

> > Does this require reserving anonymous.invalid to never resolve to
> > something real? How would you enforce that? (Maybe a new TLD for
> > "invalid" :-)  )
> 
> Fortunately, RFC2606 beat us to it. Perhaps I should list this as a
> reference.

Yes. In fact, its normative in order to ensure exactly the property ben
was worried about.

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

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



From daemon@ns.ietf.org  Fri May 31 16:43:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04207
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 16:43:41 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA03865
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:44:07 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02101;
	Fri, 31 May 2002 16:17:52 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02070
	for <sip@ns.ietf.org>; Fri, 31 May 2002 16:17:50 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03631
	for <sip@ietf.org>; Fri, 31 May 2002 16:17:21 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKIsYH028745;
	Fri, 31 May 2002 16:18:54 -0400 (EDT)
Message-ID: <3CF7DA4D.925D2F55@dynamicsoft.com>
Date: Fri, 31 May 2002 16:17:17 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bob Penfield <bpenfield@acmepacket.com>
CC: "Peterson, Jon" <jon.peterson@neustar.biz>, sip@ietf.org
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
References: <017c01c208dc$d0065b20$2300000a@acmepacket.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Bob Penfield wrote:
> 

> > > How does the user know whether privacy services are supported? Do
> they
> > > need to try it with Proxy-Require to see if the request fails?
> > >
> >
> > The text above is meant to suggest that users should know out-of-band
> that
> > their local administrative domain supports a privacy service function.
> 
> I too am quite concerned about this. It seems adaquate to say the UA
> "just
> knows" when we're talking about a P-Header with limited applicability,
> but
> not necessarily for a general purpose protocol mechanism.

Right.

> 
> However, this mechanism would use a Require header, not a Proxy-Require.
> There are very few headers mentioned in this draft that RFC 3261 allows
> a
> proxy to modify or delete. I assert that performing any user, header or
> session privacy functions in an intermediary turns the privacy service
> into
> a B2BUA. If the UA is aware that is sending to a privacy service then it
> can
> certainly be aware that it is sending to a B2BUA and include the tag in
> its
> Require header.

Hmm. The problem is that you want get the desired effect if there are no
privacy services on the path, and you thought there were. Inserting a
Require: privacy in teh request would get the request all the way to the
UAS, who then knows your identity, in addition to knowing that you
wanted to be anonymous. Seems like the worst of all cases. So, while in
theory, you might be right, practically speaking this has to be
proxy-require to work.

-Jonathan R.

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

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



From daemon@ns.ietf.org  Fri May 31 16:49:58 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04296
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 16:49:58 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA04117
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:50:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02858;
	Fri, 31 May 2002 16:30:18 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02814
	for <sip@ns.ietf.org>; Fri, 31 May 2002 16:30:15 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03863
	for <sip@ietf.org>; Fri, 31 May 2002 16:29:47 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKVFYH028761;
	Fri, 31 May 2002 16:31:15 -0400 (EDT)
Message-ID: <3CF7DD32.43D6BE52@dynamicsoft.com>
Date: Fri, 31 May 2002 16:29:38 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Elwell, John" <John.Elwell@siemenscomms.co.uk>
CC: "'jh@lohi.eng.song.fi'" <jh@lohi.eng.song.fi>,
        "'Cullen Jennings'" <fluffy@cisco.com>, sip@ietf.org
Subject: Re: [Sip] SIP WGLC of draft-ietf-sip-asserted-identity
References: <0E644D072B76C740BC1CBD2CBB51AEFE0312E5C6@Beex50.siemenscomms.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



"Elwell, John" wrote:
> 
> I had assumed that any header that was to be removed would already have
> been
> removed at this point. However, looking at the rest of the text again,
> this
> is not clear. So how about:
> 
> "The proxy MAY add a P-Asserted-Identity header field with either a
> single
> SIP URI or a single SIPS URI, provided there is not already a SIP URI or
> SIPS URI present or replacing a SIP URI or SIPS URI from an untrusted
> source.  Likewise, the proxy MAY add a P-Asserted-Identity header field
> with
> a single tel URL, provided there is not already a tel URL present or
> replacing a tel URL from an untrusted source."

THis is still awkward. Might I suggest:

If there is no P-Asserted-Identity header field present, a proxy MAY add
one containing at most one SIP or SIP URIs, and at most one tel URL. If
there is a P-Asserted-Identity header present, and it contains a SIP or
SIP URI from an untrusted source, the proxy MAY replace that SIP or SIPS
URI with a single SIP or SIP URI. If there is a P-Asserted-Identity
header present, and it contains a tel URL from an untrusted source, the
proxy MAY replace that tel URL with a single tel URL.

-Jonathan R.


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

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



From daemon@ns.ietf.org  Fri May 31 16:50:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04339
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 16:50:56 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id QAA04180
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 16:51:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02180;
	Fri, 31 May 2002 16:19:30 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA02151
	for <sip@ns.ietf.org>; Fri, 31 May 2002 16:19:27 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03662
	for <sip@ietf.org>; Fri, 31 May 2002 16:18:59 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VKKSYH028748;
	Fri, 31 May 2002 16:20:28 -0400 (EDT)
Message-ID: <3CF7DAAB.F5DED92A@dynamicsoft.com>
Date: Fri, 31 May 2002 16:18:51 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: "'Elwell, John'" <John.Elwell@siemenscomms.co.uk>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
References: <70565611B164D511957A001083FCDD5601870387@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



"Peterson, Jon" wrote:
> 
> On the first issue, yes, the examples in sip-asserted-identity go
> against
> this SHOULD in sip-privacy-general, with some good reasons. Perhaps
> those
> reasons could stand to be motivated a bit in the identity draft - but I
> don't think this is the wrong behavior, anyway.
> 
> On the second issue, the draft says if 'none' is present the privacy
> service
> MUST NOT perform any privacy function. The draft also says (section
> 4.2):
> "An intermediary MUST NOT modify the Privacy header in any way if the
> 'none'
> priv-value is already specified." So I think it should be clear that
> Privacy
> headers containing 'none' will not be removed.

I think you should explicitly note this exception. In my experience, the
more explicit you are in specs, the better.

-Jonathan R.


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

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



From daemon@ns.ietf.org  Fri May 31 17:35:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05357
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 17:35:25 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA07519
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 17:35:50 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05497;
	Fri, 31 May 2002 17:00:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05437
	for <sip@ns.ietf.org>; Fri, 31 May 2002 17:00:54 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04521
	for <sip@ietf.org>; Fri, 31 May 2002 17:00:24 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VL1oYH028796;
	Fri, 31 May 2002 17:01:51 -0400 (EDT)
Message-ID: <3CF7E45C.E2C66BC4@dynamicsoft.com>
Date: Fri, 31 May 2002 17:00:12 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
CC: "'Bob Penfield'" <bpenfield@acmepacket.com>,
        "'Peterson, Jon'" <jon.peterson@neustar.biz>, sip@ietf.org
Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
References: <005c01c208e5$56c18010$1d036e3f@TXDWILLIS2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit



Dean Willis wrote:
> 
> > Hmm. The problem is that you want get the desired effect if
> > there are no privacy services on the path, and you thought
> > there were. Inserting a
> > Require: privacy in teh request would get the request all the
> > way to the UAS, who then knows your identity, in addition to
> > knowing that you wanted to be anonymous. Seems like the worst
> > of all cases. So, while in theory, you might be right,
> > practically speaking this has to be proxy-require to work.
> 
> And you have to KNOW you have a proxy in between, otherwise the remote
> UA gets the Proxy-Require header AND your AI.

Good point. 

> 
> Query -- is the presence of the Proxy-require header in a message
> delivered to the remote UA in and of itself a privacy issue? They KNOW
> you've requested privacy . . .

The from field already says its anonymous (in all likelihood). So, I
don't see a problem.

-Jonathan R.

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

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



From daemon@ns.ietf.org  Fri May 31 17:40:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05406
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 17:40:47 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id RAA07693
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 17:41:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04421;
	Fri, 31 May 2002 16:55:59 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04387
	for <sip@ns.ietf.org>; Fri, 31 May 2002 16:55:56 -0400 (EDT)
Received: from bdsl.66.12.12.130.gte.net (bdsl.66.12.12.130.gte.net [66.12.12.130])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04458
	for <sip@ietf.org>; Fri, 31 May 2002 16:55:31 -0400 (EDT)
Received: from TXDWILLIS2 (bdsl.greycouncil.com [127.0.0.1])
	by bdsl.66.12.12.130.gte.net (8.11.6/8.11.6) with ESMTP id g4VKtC405361;
	Fri, 31 May 2002 15:55:12 -0500
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Bob Penfield'" <bpenfield@acmepacket.com>
Cc: "'Peterson, Jon'" <jon.peterson@neustar.biz>, <sip@ietf.org>
Subject: RE: [Sip] WGLC for draft-ietf-sip-privacy-general
Date: Fri, 31 May 2002 15:54:21 -0500
Message-ID: <005c01c208e5$56c18010$1d036e3f@TXDWILLIS2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <3CF7DA4D.925D2F55@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

> Hmm. The problem is that you want get the desired effect if 
> there are no privacy services on the path, and you thought 
> there were. Inserting a
> Require: privacy in teh request would get the request all the 
> way to the UAS, who then knows your identity, in addition to 
> knowing that you wanted to be anonymous. Seems like the worst 
> of all cases. So, while in theory, you might be right, 
> practically speaking this has to be proxy-require to work.

And you have to KNOW you have a proxy in between, otherwise the remote
UA gets the Proxy-Require header AND your AI.

Query -- is the presence of the Proxy-require header in a message
delivered to the remote UA in and of itself a privacy issue? They KNOW
you've requested privacy . . .

--
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 daemon@ns.ietf.org  Fri May 31 18:02:33 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05694
	for <sip-archive@odin.ietf.org>; Fri, 31 May 2002 18:02:32 -0400 (EDT)
Received: (from daemon@localhost)
	by optimus.ietf.org (8.9.1a/8.9.1) id SAA08764
	for sip-archive@odin.ietf.org; Fri, 31 May 2002 18:02:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07636;
	Fri, 31 May 2002 17:39:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07613
	for <sip@ns.ietf.org>; Fri, 31 May 2002 17:39:23 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05394
	for <sip@ietf.org>; Fri, 31 May 2002 17:38:53 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.54])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g4VLeIYH028825;
	Fri, 31 May 2002 17:40:18 -0400 (EDT)
Message-ID: <3CF7ED61.AE86452E@dynamicsoft.com>
Date: Fri, 31 May 2002 17:38:41 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: "'Mark Watson'" <mwatson@nortelnetworks.com>,
        "'Andrew Allen'" <AAllen@dynamicsoft.com>,
        "'David R. Oran'" <oran@cisco.com>, "'Rohan Mahy'" <rohan@cisco.com>,
        sip@ietf.org
Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
References: <70565611B164D511957A001083FCDD5601870354@va02.va.neustar.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

I hate to throw a wrench in here, but since we do have an oppty for
another rev of the doc during ietf LC, I would like to voice an opinion.

I don't believe that the hint should use the same header.

My reasoning is simple. A header has a particular meaning. That meaning
should be invariant to where that header appears, request or response,
or any other conditions. We have been burned HARD by this one with the
Contact header, which really has two different meanings depending on
context. It was only much later on we realized that we needed both in
the same request, but of course, its too late...

P-Asserted-Identity should mean "this is the identity asserted by the
trust domain for the originator of this message". Period. That is not at
all the same thing as "this is the identity the end user would like you
to use, assuming its one of the allowed identities for this user". In
fact, there are vastly different trust implications for the two
semantics. I can see right now a case where some misconfigured proxy
forgets to strip the "hint" and all of a sudden it becomes a fraudulent
call, since the hint was the identity of a different user.

It wouldn't shock me either if one day down the road we find we do need
both of these things in the same request. 

I don't care what you call it. But, its not P-Asserted-Identity.

-Jonathan R.


"Peterson, Jon" wrote:
> 
> Since I've never been one to fly in the face of public opinion (cough),
> I'll agree (at least in this case) that we should go with majority rule
> and use the Asserted-Identity header for the 'hint'.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> -----Original Message-----
> From: Mark Watson [mailto:mwatson@nortelnetworks.com]
> Sent: Thursday, May 23, 2002 9:18 AM
> To: 'Andrew Allen'; 'David R. Oran'; 'Peterson, Jon'; 'Rohan Mahy';
> sip@ietf.org
> Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> 
> In the absence of further comment, can I make a *proposal* that we stick
> with Asserted-Identity for the hint and for the NAI itself, and that
> both are described in Cullen's draft ?
> 
> Can we take this as AGREED if there are no comments by cob tomorrow ?
> (Guidance sought from chairs on this second question).
> 
> Updated requirements draft to be submitted first thing tomorrow.
> 
> Regards...Mark
> 
> > -----Original Message-----
> > From: Andrew Allen [ mailto:AAllen@dynamicsoft.com
> <mailto:AAllen@dynamicsoft.com> ]
> > Sent: 22 May 2002 15:51
> > To: 'David R. Oran'; Watson, Mark [MDN05:EP10:EXCH]; 'Peterson, Jon';
> > 'Rohan Mahy'; sip@ietf.org
> > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> >
> >
> >
> > I agree with Dave. Lets put the hint in the
> > asserted-identity. Lets not have
> > two redundant headers that need to be transferred over the
> > Radio interface
> > unnecessarily.
> >
> > Andrew
> >
> > > -----Original Message-----
> > > From: David R. Oran [ mailto:oran@cisco.com <mailto:oran@cisco.com>
> ]
> > > Sent: Wednesday, May 22, 2002 9:45 AM
> > > To: 'Mark Watson'; 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > >
> > >
> > > I suggest we allow the hint to be placed in the
> > > asserted-identity rather
> > > than in another header. A boundary proxy has to deal with a
> > UA putting
> > > in the header no matter what, if only to reject the request with an
> > > error.
> > >
> > > Once we have a full solution the issue of hints should go
> > > away as a side
> > > effect of having the "authorization server" functionality that Jon
> > > proposes. Better IMHO to have one obsolescent header to deal
> > > with rather
> > > than two, as well as avoiding the concomitant verbiage
> > describing the
> > > combinatoric cases involving two headers.
> > >
> > > Dave.
> > >
> > > > -----Original Message-----
> > > > From: sip-admin@ietf.org [ mailto:sip-admin@ietf.org
> <mailto:sip-admin@ietf.org> ] On
> > > > Behalf Of Mark Watson
> > > > Sent: Wednesday, May 22, 2002 9:59 AM
> > > > To: 'Peterson, Jon'; 'Rohan Mahy'; sip@ietf.org
> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > > > Importance: High
> > > >
> > > >
> > > > All,
> > > >
> > > > Can we have a *decision* asap as to whether the 'hint' uses
> > > > Asserted-Identity, or another header in another draft.
> > > >
> > > > I do not mind which. If the latter I will publish an I-D
> > > > describing it as soon as we have a decision, assuming it is
> > > > this week, since I'm away next week.
> > > >
> > > > If we do nothing, then I guess 3GPP will make up its own mind
> > > > how to do this, without supervision or advice from IETF,
> > > > which I think would  be a bad thing.
> > > >
> > > > Regards...Mark
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Watson, Mark [MDN05:EP10:EXCH]
> > > > Sent: 20 May 2002 12:08
> > > > To: 'Peterson, Jon'; 'Rohan Mahy'
> > > > Cc: sip@ietf.org
> > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > > >
> > > >
> > > > The 'hint' was one of the three requirements that 3GPP
> > > > communicated to us in April.
> > > > It is a separate requirement from the Network Asserted
> > > > Identity itself, and so is not addressed in the requirements
> > > > draft, although I have been careful to point this out, and to
> > > > point out that it is a requirement nontheless, on several
> > > > occasions. I believe we need the 'hint' in the same timeframe
> > > > as the rest of the short term work.
> > > > Whether it is the same header/draft or a different
> > > > header/draft is another question on which I will only say
> > > > that we'd better make up our minds pretty quick. ...Mark
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Peterson, Jon [ mailto:jon.peterson@neustar.biz
> <mailto:jon.peterson@neustar.biz> ]
> > > > > Sent: 19 May 2002 18:11
> > > > > To: 'Rohan Mahy'
> > > > > Cc: sip@ietf.org
> > > > > Subject: RE: [Sip] Asserted-Identity: How to 'hint'?
> > > > >
> > > > >
> > > > >
> > > > > My argument was not that the proposed hint won't work - just
> > > > > that it isn't
> > > > > necessary to solve the problem at hand. It might not be the
> > > > > case that the
> > > > > problems with the hint stop at the philosophical point you
> > > > > mention below.
> > > > > What I asked in my last mail was not whether or not we needed
> > > > > a hint, but
> > > > > rather whether or not we should table that question until we
> > > > > resolve the
> > > > > other questions at hand. I just don't want to spend the
> > > > > cycles arguing about
> > > > > the hint given our very aggressive timetable - frankly, I
> > > > think that
> > > > > reaching consensus on this hint matter might push back our
> > > > > dates a bit.
> > > > > Let's investigate this hint stuff in June, but for now just
> > > > > figure out how a
> > > > > Trust Domain can manage an asserted identity in a message.
> > > > >
> > > > > Jon Peterson
> > > > > NeuStar, Inc.
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Rohan Mahy [ mailto:rohan@cisco.com
> <mailto:rohan@cisco.com> ]
> > > > > > Sent: Sunday, May 19, 2002 8:29 AM
> > > > > > To: Peterson, Jon
> > > > > > Cc: sip@ietf.org
> > > > > > Subject: Re: [Sip] Asserted-Identity: How to 'hint'?
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > The requirement for a hint is well understood, limited in
> > > > > > scope, and well motivated in the draft.  Nobody has
> > identified
> > > > > > any technical reason why the hint won't work.   Your argument
> > > > > > that allowing a hint weakens the strength of the language on
> > > > > > ignoring Asserted-Identity from untrusted parties is purely
> > > > > > philosophical in nature.  I don't buy your argument.
> > > > > >
> > > > > > thanks,
> > > > > > -rohan
> > > > > >
> > > > > >
> > > > > > ---- Original message ----
> > > > > > >Date: Fri, 17 May 2002 16:02:11 -0500
> > > > > > >From: "Peterson, Jon" <jon.peterson@neustar.biz>
> > > > > > >Subject: [Sip] Asserted-Identity: How to 'hint'?
> > > > > > >To: "'sip@ietf.org'" <sip@ietf.org>
> > > > > > >
> > > > > > >
> > > > > > >In the course of the discussion between Mark Watson, Cullen
> > > > > > Jennings and
> > > > > > >myself about the short-term identity work, we have returned a
> 
> > > > > > few times to
> > > > > > >the question of the infamous hint. This hint is, of course, a
> 
> > > > > > way that a
> > > > > > >user agent (one that is not a member of the Trust Domain in
> > > > > > the short-term
> > > > > > >network asserted identity space) can provide a 'hint' to the
> > > > > > intermediary
> > > > > > >that will generate an Asserted-Identity indicating which
> > > > > > identity among
> > > > > > >several possibilities should be asserted.
> > > > > > >
> > > > > > >The need for this arises particularly from the 3G space, in
> > > > > > which the
> > > > > > >authentication process takes place independently of SIP and
> > > > > > does not carry
> > > > > > >this sort of personal identity information. It also assumes
> > > > > > that the
> > > > > > >operators of the intermediary in question are aware of
> > > > > > several legitimate
> > > > > > >identities which the user can elect to assert.
> > > > > > >
> > > > > > >It has been proposed on the mailing list and
> > elsewhere that the
> > > > > > >Asserted-Identity header should be re-used by user agents
> > > > > > outside the Trust
> > > > > > >Domain to provide such a hint. I see a number of reasons for
> > > > > > and against
> > > > > > >using the Asserted-Identity for this purpose. For example,
> > > > > > today, there is a
> > > > > > >requirement that asserted-identities which are transmitted
> > > > > > from untrusted
> > > > > > >sources should not be used in any way - this would seem to
> > > > > > weaken that
> > > > > > >requirement. There is also possibly some behavior that still
> > > > > > needs to be
> > > > > > >specified (like how an intermediary would reject or otherwise
> 
> > > > > > handle a
> > > > > > >request with an inappropriate hint) that might be impactful
> > > > > > to our choice.
> > > > > > >
> > > > > > >For the time being, however, I would like to suggest that
> > > > > > providing the hint
> > > > > > >is outside the scope of the current deliverables (the
> > > > > > asserted-identity
> > > > > > >requirements and mechanism drafts), which need to be
> > > > > > complete, as we
> > > > > > >discussed in the interim meeting, by the end of this month. I
> 
> > > > > > believe that a
> > > > > > >separate draft should propose the use of Asserted-Identity or
> 
> > > > > > any other
> > > > > > >header for this hint (in whatever timeframe is appropriate
> > > > > > for 3G's
> > > > > > >requirements), but that we should not speak to this matter in
> 
> > > > > > the current
> > > > > > >asserted-identity deliverables. There is, as I see it, no
> > > > > > dependency on
> > > > > > >defining this hint before we dictate how intermediaries will
> > > > > > assert
> > > > > > >identities.
> > > > > > >
> > > > > > >Any comments on this plan?
> > > > > > >
> > > > > > >Jon Peterson
> > > > > > >NeuStar, Inc.
> > > > > > >
> > > > > > >_______________________________________________
> > > > > > >Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> <https://www1.ietf.org/mailman/listinfo/sip>
> > > > > > >This list is for NEW development of the core SIP 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
> <https://www1.ietf.org/mailman/listinfo/sip>
> > > > > This list is for NEW development of the core SIP 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
> <https://www1.ietf.org/mailman/listinfo/sip>
> > > > This list is for NEW development of the core SIP 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
> <https://www1.ietf.org/mailman/listinfo/sip>
> > > This list is for NEW development of the core SIP 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.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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