From exim@www1.ietf.org  Mon Dec  1 00:12:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25630
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 00:12:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQgM6-0002Op-2y
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 00:12:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB15CIbm009219
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 00:12:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQgLp-0002Nx-Ao; Mon, 01 Dec 2003 00:12:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQgLm-0002Nh-Rh
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 00:11:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25615
	for <sip@ietf.org>; Mon, 1 Dec 2003 00:11:43 -0500 (EST)
From: kowsalya@npd.hcltech.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQgLk-0002wl-00
	for sip@ietf.org; Mon, 01 Dec 2003 00:11:56 -0500
Received: from [203.199.199.232] (helo=hclnpd.hclt-guindy.co.in)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQgLj-0002wf-00
	for sip@ietf.org; Mon, 01 Dec 2003 00:11:55 -0500
Received: from pilex.hclt-ntl.co.in ([192.168.19.34]) by hclnpd.hclt-guindy.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id VL2HDPQC; Mon, 1 Dec 2003 10:41:47 +0530
Received: by PILEX with Internet Mail Service (5.5.2653.19)
	id <WKBGG8ZZ>; Mon, 1 Dec 2003 10:41:25 +0530
Message-ID: <50D40047DC73D611BDA60050BAC4EDD9A99EB4@PILEX>
To: gktvm2@yahoo.com, sip@ietf.org
Subject: RE: [Sip] Query on PRACK
Date: Mon, 1 Dec 2003 10:41:25 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B7C9.91902B80"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

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_01C3B7C9.91902B80
Content-Type: text/plain;
	charset="iso-8859-1"

Gokul,
 
PRACK is just like any other non-INVITE transaction and hence does not
require an ACK by UAC.
 
1. UAC sends an INVITE
2. UAS responds with a reliable provisional response
3. UAC sends a PRACK
4. UAS responds to PRACK with a 200 OK
5. UAS sends 200 OK for INVITE
6. UAC sends ACK for the original INVITE transaction
 
Thanks
Kowsalya
 
 

-----Original Message-----
From: Gokul Krishnan [mailto:gktvm2@yahoo.com]
Sent: Saturday, November 29, 2003 5:44 PM
To: sip@ietf.org
Subject: [Sip] Query on PRACK


Hi All,
 
Does PRACK trigger another 2XX response ? If yes, does that mean UAC should
send an ACK? Can any one please provide a message sequence flow?
 
  If a PRACK request is received by the UA core that does not
  match any unacknowledged reliable provisional response, the 
  UAS MUST respond to the PRACK with a 481 response.  If the
  PRACK does match an unacknowledged reliable provisional
  response, it MUST be responded to with a 2xx response.  
  (RFC 3262, Page 5)


Thanks and Regards
Gokul



  _____  

Do you Yahoo!?
Free  <http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/>
Pop-Up Blocker - Get it now


------_=_NextPart_001_01C3B7C9.91902B80
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 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2>Gokul,</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" size=2>PRACK is 
just like any other non-INVITE transaction and hence does not require an ACK by 
UAC.</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" size=2>1. UAC sends 
an INVITE</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" size=2>2. UAS 
responds with a reliable provisional response</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" size=2>3. UAC sends 
a PRACK</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" size=2>4. UAS 
responds to PRACK with a 200 OK</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" size=2>5. UAS sends 
200 OK for INVITE</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" size=2>6. UAC sends 
ACK for the original INVITE transaction</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2>Thanks</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2>Kowsalya</FONT></SPAN></DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=292570205-01122003><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gokul Krishnan 
  [mailto:gktvm2@yahoo.com]<BR><B>Sent:</B> Saturday, November 29, 2003 5:44 
  PM<BR><B>To:</B> sip@ietf.org<BR><B>Subject:</B> [Sip] Query on 
  PRACK<BR><BR></FONT></DIV>
  <DIV>
  <DIV><FONT face=Verdana color=#800000 size=2><SPAN class=320184811-29112003>Hi 
  All,</SPAN></FONT></DIV>
  <DIV><FONT face=Verdana color=#800000 size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Verdana><FONT color=#800000 size=2>Does PRACK trigger another 
  2XX response ?&nbsp;<SPAN class=320184811-29112003>If yes, does that 
  mean&nbsp;</SPAN><SPAN class=320184811-29112003>UAC should send 
  an</SPAN>&nbsp;ACK? Can&nbsp;<SPAN class=320184811-29112003>any 
  one</SPAN>&nbsp;please provide a message sequence&nbsp;<SPAN 
  class=320184811-29112003>flow</SPAN>?</FONT></FONT></DIV>
  <DIV><FONT face=Verdana color=#800000 size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Verdana color=#800000><FONT size=2><FONT face="Courier New" 
  color=#000000>&nbsp; If a PRACK request is received by the UA core that does 
  not</FONT></FONT></FONT></DIV>
  <DIV><FONT face=Verdana color=#800000><FONT size=2><FONT face="Courier New" 
  color=#000000>&nbsp;&nbsp;match any&nbsp;unacknowledged reliable provisional 
  response, the </FONT></FONT></FONT></DIV>
  <DIV><FONT face=Verdana color=#800000><FONT size=2><FONT face="Courier New" 
  color=#000000>&nbsp; UAS MUST respond to&nbsp;the PRACK with a 481 
  response.&nbsp; If the</FONT></FONT></FONT></DIV>
  <DIV><FONT face=Verdana color=#800000><FONT size=2><FONT face="Courier New" 
  color=#000000>&nbsp; PRACK does match an&nbsp;unacknowledged reliable 
  provisional</FONT></FONT></FONT></DIV>
  <DIV><FONT face=Verdana color=#800000><FONT size=2><FONT face="Courier New" 
  color=#000000>&nbsp; response, it MUST be responded to&nbsp;with a 2xx 
  response.</FONT>&nbsp;<SPAN class=320184811-29112003><FONT face="Courier New" 
  color=#000000> </FONT></SPAN></FONT></FONT></DIV>
  <DIV><FONT face=Verdana color=#800000><FONT size=2><SPAN 
  class=320184811-29112003><FONT face="Courier New" color=#000000>&nbsp; 
  (<STRONG>RFC 3262, Page 5</STRONG>)</FONT></SPAN></FONT></FONT></DIV>
  <DIV>
  <DIV><SPAN class=320184811-29112003><FONT face=Verdana color=#800000 
  size=2></FONT></SPAN></DIV><SPAN class=320184811-29112003><FONT face=Verdana 
  color=#800000 size=2></FONT></SPAN></DIV>
  <DIV><SPAN class=320184811-29112003><FONT face=Verdana color=#800000 
  size=2>Thanks and Regards</FONT></SPAN></DIV>
  <DIV><SPAN class=320184811-29112003><FONT face=Verdana color=#800000 
  size=2>Gokul</FONT></SPAN></DIV></DIV>
  <P>
  <HR SIZE=1>
  Do you Yahoo!?<BR><A 
  href="http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/">Free 
  Pop-Up Blocker - Get it now</A></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B7C9.91902B80--

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



From exim@www1.ietf.org  Mon Dec  1 09:20:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11323
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 09:20:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQouS-0001Lj-Cz
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 09:20:20 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EKK2V005127
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 09:20:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQouA-0001JW-Pv; Mon, 01 Dec 2003 09:20:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQotj-0001IY-QP
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 09:19:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11297
	for <sip@ietf.org>; Mon, 1 Dec 2003 09:19:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQoti-0002Hv-00
	for sip@ietf.org; Mon, 01 Dec 2003 09:19:34 -0500
Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQoth-0002Hs-00
	for sip@ietf.org; Mon, 01 Dec 2003 09:19:33 -0500
Received: from pcasveren (localhost [127.0.0.1])
	by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id JAA19403
	for <sip@ietf.org>; Mon, 1 Dec 2003 09:19:32 -0500 (EST)
From: "Tolga Asveren" <asveren@ulticom.com>
To: <sip@ietf.org>
Date: Mon, 1 Dec 2003 09:18:56 -0500
Message-ID: <GBEBKGPKHGPAOFCLBNAMEEIMCCAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_01EA_01C3B7EC.25B7C030"
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: <50D40047DC73D611BDA60050BAC4EDD9A99EB4@PILEX>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: [Sip] remote terget update
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


This is a multi-part message in MIME format.

------=_NextPart_000_01EA_01C3B7EC.25B7C030
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

(due to no response in sip-implementors list switching to sip list)

If a reINVITE with target refresh rejected, should remote target reverted
back to its original value before that reINVITE is received?

  Tolga

------=_NextPart_000_01EA_01C3B7EC.25B7C030
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D828351514-01122003>(due to no=20
response in sip-implementors list switching to sip =
list)</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D828351514-01122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D828351514-01122003>If a=20
reINVITE with target refresh rejected, should remote target reverted =
back to its=20
original value before that reINVITE is received?</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D828351514-01122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D828351514-01122003>&nbsp;=20
Tolga</SPAN></FONT></DIV></BODY></HTML>

------=_NextPart_000_01EA_01C3B7EC.25B7C030--


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



From exim@www1.ietf.org  Mon Dec  1 09:33:23 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12118
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 09:33:23 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQp6p-0002Dy-Lp
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 09:33:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EX77S008532
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 09:33:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQp6j-0002CP-70; Mon, 01 Dec 2003 09:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQp5w-000262-JW
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 09:32:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12025
	for <sip@ietf.org>; Mon, 1 Dec 2003 09:31:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQp5u-0002eX-00
	for sip@ietf.org; Mon, 01 Dec 2003 09:32:10 -0500
Received: from mail4.dynamicsoft.com ([63.110.3.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQp5u-0002ap-00
	for sip@ietf.org; Mon, 01 Dec 2003 09:32:10 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hB1EVVZA008159;
	Mon, 1 Dec 2003 08:31:31 -0600 (CST)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YBTH5SJJ>; Mon, 1 Dec 2003 08:31:30 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E8666C@dyn-tx-exch-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'hisham.khartabil@nokia.com'" <hisham.khartabil@nokia.com>,
        Adam Roach <adam@dynamicsoft.com>, fluffy@cisco.com, vkg@lucent.com
Cc: sip@ietf.org
Subject: RE: [Sip] SCTP and TLS
Date: Wed, 26 Nov 2003 12:26:23 -0600
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


I thought of throwing that in as another example
of a kind of change that isn't backwards compatible.
The problem is, keeping the necessary state also
disqualified it from being elegant, so I didn't
see any advantage that made it worth mentioning.

/a

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: Wednesday, November 26, 2003 1:02
> To: adam@dynamicsoft.com; fluffy@cisco.com; vkg@lucent.com
> Cc: sip@ietf.org
> Subject: RE: [Sip] SCTP and TLS
> 
> 
> Why isn't it enough to state that if a request was received 
> using TLS, the response must sent using TLS? It requires 
> proxies and UASs to keep a state though.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext
> > Adam Roach
> > Sent: 26.November.2003 07:10
> > To: 'Cullen Jennings'; Vijay Gurbani
> > Cc: Adam Roach; sip@ietf.org
> > Subject: RE: [Sip] SCTP and TLS
> > 
> > 
> > Cullen Jennings [mailto:fluffy@cisco.com] wrote:
> > 
> > > There is not really any SCTP or TLS over SCTP or UDP or DCCP 
> > > deployed so I think we could be backwards compatible with
> > > existing TLS stuff. I'm not seeing a way to be backwards
> > > compatible with everything but the current stuff looks broken
> > > so I think the odds of something other than what is currently
> > > specified deploying are fairly high. This is not a "I don't
> > > like the current thing issues" this is the current thing can't 
> > > construct a usable via for a stateless proxy using SCTP with TLS.
> > 
> > Actually, I think we have a choice between backwards-compatibility
> > and elegance.
> > 
> > For example, we could choose designations like the following
> > for a sort of elegance:
> > 
> > UDP:       SIP/2.0/UDP
> > UDP+TLS:   SIP/2.0/TLS/UDP
> > TCP:       SIP/2.0/TCP
> > TCP+TLS:   SIP/2.0/TLS/TCP
> > SCTP:      SIP/2.0/SCTP
> > SCTP+TLS:  SIP/2.0/TLS/SCTP
> > DCCP:      SIP/2.0/DCCP
> > DCCP+TLS:  SIP/2.0/TLS/DCCP
> > 
> > Alternately, we could retain backwards compatibility (but have
> > people forever wonder about the TCP aberration) by using
> > designations like:
> > 
> > UDP:       SIP/2.0/UDP
> > UDP+TLS:   SIP/2.0/TLS/UDP
> > TCP:       SIP/2.0/TCP
> > TCP+TLS:   SIP/2.0/TLS
> > SCTP:      SIP/2.0/SCTP
> > SCTP+TLS:  SIP/2.0/TLS/SCTP
> > DCCP:      SIP/2.0/DCCP
> > DCCP+TLS:  SIP/2.0/TLS/DCCP
> > 
> > Because of practical considerations, I would propose that the
> > second approach is probably the best path forward.
> > 
> > /a
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Dec  1 09:36:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12204
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 09:36:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQp9o-0002eV-7O
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 09:36:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1EaCKI010136
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 09:36:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQp9f-0002YG-Le; Mon, 01 Dec 2003 09:36:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQp90-0002X3-Uv
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 09:35:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12173
	for <sip@ietf.org>; Mon, 1 Dec 2003 09:35:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQp8x-0002i9-00
	for sip@ietf.org; Mon, 01 Dec 2003 09:35:19 -0500
Received: from mailgate.pit.comms.marconi.com ([169.144.68.6])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQp8x-0002hk-00
	for sip@ietf.org; Mon, 01 Dec 2003 09:35:19 -0500
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 JAA24561;
	Mon, 1 Dec 2003 09:34:46 -0500 (EST)
Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08861;
	Mon, 1 Dec 2003 09:34:47 -0500 (EST)
Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19)
	id <W9W75ZRS>; Mon, 1 Dec 2003 09:34:46 -0500
Message-ID: <313680C9A886D511A06000204840E1CF070B6134@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'vhegde@san.rr.com'" <vhegde@san.rr.com>, sip@ietf.org
Subject: RE: [Sip] Session timer question
Date: Mon, 1 Dec 2003 09:34: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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

You send 420  - Bad Extension, because you don't understand the
timer option in the Require.  See section 8.2.2.3 in RFC3261.

Brian
-----Original Message-----
From: vhegde@san.rr.com [mailto:vhegde@san.rr.com]
Sent: Friday, November 28, 2003 9:13 PM
To: sip@ietf.org
Subject: [Sip] Session timer question


Hi:
I have a question on session timer message flow.

 If a UA does not support session timer and if it receives 

Require: timer
Session Expires: 3600 

in the 200 OK to re-INVITE what is the correct way to process this response?


Should UAC Ack the 200 OK and then send a bye or ignore the Require and
session Expires: headers and continue with rest of the processing?

Veda

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



From exim@www1.ietf.org  Mon Dec  1 10:38:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15164
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 10:38:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQq82-000618-6v
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 10:38:26 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1FcPxw023071
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 10:38:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQq7e-0005vd-Oh; Mon, 01 Dec 2003 10:38:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQq6n-0005kq-Si
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 10:37:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15113
	for <sip@ietf.org>; Mon, 1 Dec 2003 10:36:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQq6l-0003Q6-00
	for sip@ietf.org; Mon, 01 Dec 2003 10:37:07 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQq6l-0003Pw-00
	for sip@ietf.org; Mon, 01 Dec 2003 10:37:07 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 07:39:19 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1FaXAt029310;
	Mon, 1 Dec 2003 07:36:33 -0800 (PST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEI10960;
	Mon, 1 Dec 2003 10:36:32 -0500 (EST)
Message-ID: <3FCB5FFE.7010208@cisco.com>
Date: Mon, 01 Dec 2003 10:36:30 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
CC: "'vhegde@san.rr.com'" <vhegde@san.rr.com>, sip@ietf.org
Subject: Re: [Sip] Session timer question
References: <313680C9A886D511A06000204840E1CF070B6134@whq-msgusr-02.pit.comms.marconi.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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Brian,

The question was about a Require in a 200 response to an invite. The UAC 
clearly can't return a 420 in that case.

I don't think any valid usage of session timer will ever result in this 
case. The only cases where Require: timer is validly put into the 
response are when the request contained Supported: timer.

So this can only result from a broken proxy or UAS. In this case I think 
the UAC is justified in either sending an ACK and then BYE as you 
suggest, or else just ignoring the Required: timer.

	Paul

Rosen, Brian wrote:
> You send 420  - Bad Extension, because you don't understand the
> timer option in the Require.  See section 8.2.2.3 in RFC3261.
> 
> Brian
> -----Original Message-----
> From: vhegde@san.rr.com [mailto:vhegde@san.rr.com]
> Sent: Friday, November 28, 2003 9:13 PM
> To: sip@ietf.org
> Subject: [Sip] Session timer question
> 
> 
> Hi:
> I have a question on session timer message flow.
> 
>  If a UA does not support session timer and if it receives 
> 
> Require: timer
> Session Expires: 3600 
> 
> in the 200 OK to re-INVITE what is the correct way to process this response?
> 
> 
> Should UAC Ack the 200 OK and then send a bye or ignore the Require and
> session Expires: headers and continue with rest of the processing?
> 
> Veda
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Dec  1 11:44:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17222
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 11:44:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQr9u-0000yc-1O
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 11:44:26 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1GiPtA003748
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 11:44:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQr9V-0000xA-KJ; Mon, 01 Dec 2003 11:44:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQr99-0000wc-PH
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 11:43:39 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17162
	for <sip@ietf.org>; Mon, 1 Dec 2003 11:43:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQr98-0004yU-00
	for sip@ietf.org; Mon, 01 Dec 2003 11:43:38 -0500
Received: from web12704.mail.yahoo.com ([216.136.173.241])
	by ietf-mx with smtp (Exim 4.12)
	id 1AQr97-0004yR-00
	for sip@ietf.org; Mon, 01 Dec 2003 11:43:38 -0500
Message-ID: <20031201164335.19058.qmail@web12704.mail.yahoo.com>
Received: from [128.107.253.38] by web12704.mail.yahoo.com via HTTP; Mon, 01 Dec 2003 08:43:35 PST
Date: Mon, 1 Dec 2003 08:43:35 -0800 (PST)
From: Gokul Krishnan <gktvm2@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1804434909-1070297015=:18442"
Subject: [Sip] Query on Extensions
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0-1804434909-1070297015=:18442
Content-Type: text/plain; charset=us-ascii

Hi All,
 
What is the difference between "Allow" and "Supported" header from a usage perspective?  

As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311). 
 
What is the advantage/disadvantage of each approach?
 
Thanks and Regards
Gokul



---------------------------------
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
--0-1804434909-1070297015=:18442
Content-Type: text/html; charset=us-ascii

<DIV>
<DIV><FONT face=verdana color=#800000>Hi All,</FONT></DIV>
<DIV><FONT face=verdana color=#800000></FONT>&nbsp;</DIV>
<DIV><FONT face=verdana color=#800000>What is the difference between "Allow" and "Supported" header <STRONG>from a usage perspective</STRONG>? </FONT>
<DIV>&nbsp;</DIV></DIV>
<DIV><FONT face=verdana color=#800000>As an example, for PRACK an UAC sends Supported:100rel (RFC 3262)&nbsp;and for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311). </FONT></DIV>
<DIV><FONT face=verdana color=#800000></FONT>&nbsp;</DIV>
<DIV><FONT face=verdana color=#800000>W</FONT><FONT face=verdana color=#800000>hat is the advantage/disadvantage&nbsp;of each approach?</FONT></DIV>
<DIV><FONT face=verdana color=#800000></FONT>&nbsp;</DIV>
<DIV><FONT face=verdana color=#800000>Thanks and Regards</FONT></DIV>
<DIV><FONT face=verdana color=#800000>Gokul</FONT></DIV></DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/">Free Pop-Up Blocker - Get it now</a>
--0-1804434909-1070297015=:18442--

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



From exim@www1.ietf.org  Mon Dec  1 12:51:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19856
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 12:51:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsCd-0005Aj-MV
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 12:51:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1HpIqw019819
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 12:51:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsCM-00058f-5W; Mon, 01 Dec 2003 12:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsBj-000578-6I
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 12:50:23 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19828
	for <sip@ietf.org>; Mon, 1 Dec 2003 12:50:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsBh-0005v8-00
	for sip@ietf.org; Mon, 01 Dec 2003 12:50:21 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsBg-0005v2-00
	for sip@ietf.org; Mon, 01 Dec 2003 12:50:21 -0500
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1Hnlxg014972;
	Mon, 1 Dec 2003 12:49:47 -0500 (EST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEI23706;
	Mon, 1 Dec 2003 12:49:45 -0500 (EST)
Message-ID: <3FCB7F39.6090205@cisco.com>
Date: Mon, 01 Dec 2003 12:49:45 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gokul Krishnan <gktvm2@yahoo.com>
CC: sip@ietf.org
Subject: Re: [Sip] Query on Extensions
References: <20031201164335.19058.qmail@web12704.mail.yahoo.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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Gokul Krishnan wrote:
> Hi All,
>  
> What is the difference between "Allow" and "Supported" header *from a 
> usage perspective*?
>  
> As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and 
> for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).

"Allow" identifies sip *methods* that the UA supports. "Supported" 
identifies named "packages" that the UA supports. The values are drawn 
from different namespaces.

> What is the advantage/disadvantage of each approach?

They aren't substitutes for one another. A package listed as Supported 
may require the use of certain methods. Those methods should also be 
listed in an Allow header.

An example of this is 100rel. You need to specify both Allow: UPDATE and 
Supported: 100rel to use reliable provisional responses.

	Paul


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



From exim@www1.ietf.org  Mon Dec  1 13:29:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21569
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 13:29:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsnM-0008ST-Gh
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 13:29:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1ITGJS032512
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 13:29:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsn7-0008RD-Nx; Mon, 01 Dec 2003 13:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQsmA-0008Pu-6L
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 13:28:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21506
	for <sip@ietf.org>; Mon, 1 Dec 2003 13:27:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsm8-0006OA-00
	for sip@ietf.org; Mon, 01 Dec 2003 13:28:00 -0500
Received: from [66.192.6.226] (helo=pope.teraglobal.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQsm7-0006NY-00
	for sip@ietf.org; Mon, 01 Dec 2003 13:27:59 -0500
Received: from WXPvhegde ([66.192.6.37]) by pope.teraglobal.com
          (Netscape Messaging Server 4.15) with SMTP id HP8BLE00.3IM; Mon,
          1 Dec 2003 10:34:26 -0800 
Message-ID: <001b01c3b838$c4219380$2506c042@WXPvhegde>
From: "Veda Hegde" <vhegde@san.rr.com>
To: "Paul Kyzivat" <pkyzivat@cisco.com>,
        "Rosen Brian" <Brian.Rosen@marconi.com>
Cc: <sip@ietf.org>
References: <313680C9A886D511A06000204840E1CF070B6134@whq-msgusr-02.pit.comms.marconi.com> <3FCB5FFE.7010208@cisco.com>
Subject: Re: [Sip] Session timer question
Date: Mon, 1 Dec 2003 10:27:24 -0800
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi:
I don't think it says in the draft that a proxy/UAS can not put Require:
timer in 2xx, if UAC did not include Supported: timer in the request.
May be this should be specified in the draft.
Veda


----- Original Message -----
From: "Paul Kyzivat" <pkyzivat@cisco.com>
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Cc: <vhegde@san.rr.com>; <sip@ietf.org>
Sent: Monday, December 01, 2003 7:36 AM
Subject: Re: [Sip] Session timer question


> Brian,
>
> The question was about a Require in a 200 response to an invite. The UAC
> clearly can't return a 420 in that case.
>
> I don't think any valid usage of session timer will ever result in this
> case. The only cases where Require: timer is validly put into the
> response are when the request contained Supported: timer.
>
> So this can only result from a broken proxy or UAS. In this case I think
> the UAC is justified in either sending an ACK and then BYE as you
> suggest, or else just ignoring the Required: timer.
>
> Paul
>
> Rosen, Brian wrote:
> > You send 420  - Bad Extension, because you don't understand the
> > timer option in the Require.  See section 8.2.2.3 in RFC3261.
> >
> > Brian
> > -----Original Message-----
> > From: vhegde@san.rr.com [mailto:vhegde@san.rr.com]
> > Sent: Friday, November 28, 2003 9:13 PM
> > To: sip@ietf.org
> > Subject: [Sip] Session timer question
> >
> >
> > Hi:
> > I have a question on session timer message flow.
> >
> >  If a UA does not support session timer and if it receives
> >
> > Require: timer
> > Session Expires: 3600
> >
> > in the 200 OK to re-INVITE what is the correct way to process this
response?
> >
> >
> > Should UAC Ack the 200 OK and then send a bye or ignore the Require and
> > session Expires: headers and continue with rest of the processing?
> >
> > Veda
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Dec  1 13:42:24 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22004
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 13:42:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQszq-00011E-Da
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 13:42:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1IgAw5003917
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 13:42:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQszh-00010P-Si; Mon, 01 Dec 2003 13:42:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQszb-000108-MU
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 13:41:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21960
	for <sip@ietf.org>; Mon, 1 Dec 2003 13:41:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQszZ-0006Yg-00
	for sip@ietf.org; Mon, 01 Dec 2003 13:41:53 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQszY-0006Xy-00
	for sip@ietf.org; Mon, 01 Dec 2003 13:41:52 -0500
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB1IfI005571
	for <sip@ietf.org>; Mon, 1 Dec 2003 12:41:18 -0600 (CST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59)
	id <4M3XPQJ4>; Mon, 1 Dec 2003 18:41:16 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Veda Hegde'" <vhegde@san.rr.com>, Paul Kyzivat <pkyzivat@cisco.com>,
        Rosen Brian <Brian.Rosen@marconi.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Session timer question
Date: Mon, 1 Dec 2003 18:41:05 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I think this is answered by subclause 8.2.4 of RFC 3261, viz:

8.2.4 Applying Extensions

   A UAS that wishes to apply some extension when generating the
   response MUST NOT do so unless support for that extension is
   indicated in the Supported header field in the request.  If the
   desired extension is not supported, the server SHOULD rely only on
   baseline SIP and any other extensions supported by the client.  In
   rare circumstances, where the server cannot process the request
   without the extension, the server MAY send a 421 (Extension Required)
   response.  This response indicates that the proper response cannot be
   generated without support of a specific extension.  The needed
   extension(s) MUST be included in a Require header field in the
   response.  This behavior is NOT RECOMMENDED, as it will generally
   break interoperability.

   Any extensions applied to a non-421 response MUST be listed in a
   Require header field included in the response.  Of course, the server
   MUST NOT apply extensions not listed in the Supported header field in
   the request.  As a result of this, the Require header field in a
   response will only ever contain option tags defined in standards-
   track RFCs.

regards

Keith

> -----Original Message-----
> From: Veda Hegde [mailto:vhegde@san.rr.com]
> Sent: 01 December 2003 18:27
> To: Paul Kyzivat; Rosen Brian
> Cc: sip@ietf.org
> Subject: Re: [Sip] Session timer question
> 
> 
> Hi:
> I don't think it says in the draft that a proxy/UAS can not 
> put Require:
> timer in 2xx, if UAC did not include Supported: timer in the request.
> May be this should be specified in the draft.
> Veda
> 
> 
> ----- Original Message -----
> From: "Paul Kyzivat" <pkyzivat@cisco.com>
> To: "Rosen, Brian" <Brian.Rosen@marconi.com>
> Cc: <vhegde@san.rr.com>; <sip@ietf.org>
> Sent: Monday, December 01, 2003 7:36 AM
> Subject: Re: [Sip] Session timer question
> 
> 
> > Brian,
> >
> > The question was about a Require in a 200 response to an 
> invite. The UAC
> > clearly can't return a 420 in that case.
> >
> > I don't think any valid usage of session timer will ever 
> result in this
> > case. The only cases where Require: timer is validly put into the
> > response are when the request contained Supported: timer.
> >
> > So this can only result from a broken proxy or UAS. In this 
> case I think
> > the UAC is justified in either sending an ACK and then BYE as you
> > suggest, or else just ignoring the Required: timer.
> >
> > Paul
> >
> > Rosen, Brian wrote:
> > > You send 420  - Bad Extension, because you don't understand the
> > > timer option in the Require.  See section 8.2.2.3 in RFC3261.
> > >
> > > Brian
> > > -----Original Message-----
> > > From: vhegde@san.rr.com [mailto:vhegde@san.rr.com]
> > > Sent: Friday, November 28, 2003 9:13 PM
> > > To: sip@ietf.org
> > > Subject: [Sip] Session timer question
> > >
> > >
> > > Hi:
> > > I have a question on session timer message flow.
> > >
> > >  If a UA does not support session timer and if it receives
> > >
> > > Require: timer
> > > Session Expires: 3600
> > >
> > > in the 200 OK to re-INVITE what is the correct way to process this
> response?
> > >
> > >
> > > Should UAC Ack the 200 OK and then send a bye or ignore 
> the Require and
> > > session Expires: headers and continue with rest of the processing?
> > >
> > > Veda
> > >
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Dec  1 14:21:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23423
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 14:21:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQtbh-00038v-RX
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 14:21:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JLHpP012021
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 14:21:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQtbT-00036b-B4; Mon, 01 Dec 2003 14:21:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQtaw-0002yS-6m
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 14:20:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23317
	for <sip@ietf.org>; Mon, 1 Dec 2003 14:20:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQtat-00074l-00
	for sip@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500
Received: from pine.neustar.com ([209.173.57.70])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQtat-00074P-00
	for sip@ietf.org; Mon, 01 Dec 2003 14:20:27 -0500
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11])
	by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hB1JJBb9022753;
	Mon, 1 Dec 2003 19:19:11 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <WAAQCHYS>; Mon, 1 Dec 2003 14:19:11 -0500
Message-ID: <A9DECB0B8A01A54DBECC03B25D29513CD564BC@stntexch03.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Rene Bartsch'" <ml@bartschnet.de>, "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] ENUM-support in SIP-protocol?
Date: Mon, 1 Dec 2003 14:19:04 -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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


See:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-04.txt

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rene Bartsch [mailto:ml@bartschnet.de]
> Sent: Saturday, November 29, 2003 11:26 AM
> To: sip@ietf.org
> Subject: [Sip] ENUM-support in SIP-protocol?
> 
> 
> Hi,
> 
> first I'm new to the list, so hello to all! :-)
> 
> My question is if there is any draft of plan to implement ENUM-lookups 
> into the SIP-protocol?
> 
> Rene Bartsch
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Dec  1 14:33:20 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23971
	for <sip-archive@odin.ietf.org>; Mon, 1 Dec 2003 14:33:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQtn8-0003kh-DH
	for sip-archive@odin.ietf.org; Mon, 01 Dec 2003 14:33:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JX6pp014405
	for sip-archive@odin.ietf.org; Mon, 1 Dec 2003 14:33:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQtn3-0003j5-Ci; Mon, 01 Dec 2003 14:33:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AQtm3-0003g3-Uk
	for sip@optimus.ietf.org; Mon, 01 Dec 2003 14:32:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23882
	for <sip@ietf.org>; Mon, 1 Dec 2003 14:31:43 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQtm1-0007B9-00
	for sip@ietf.org; Mon, 01 Dec 2003 14:31:57 -0500
Received: from [66.192.6.226] (helo=pope.teraglobal.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AQtm0-0007Al-00
	for sip@ietf.org; Mon, 01 Dec 2003 14:31:56 -0500
Received: from WXPvhegde ([66.192.6.37]) by pope.teraglobal.com
          (Netscape Messaging Server 4.15) with SMTP id HP8EK300.JGT; Mon,
          1 Dec 2003 11:38:27 -0800 
Message-ID: <001001c3b841$b5c99d60$2506c042@WXPvhegde>
From: "Veda Hegde" <vhegde@san.rr.com>
To: "Drage Keith \(Keith\)" <drage@lucent.com>,
        "Paul Kyzivat" <pkyzivat@cisco.com>,
        "Rosen Brian" <Brian.Rosen@marconi.com>
Cc: <sip@ietf.org>
References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com>
Subject: Re: [Sip] Session timer question
Date: Mon, 1 Dec 2003 11:31:25 -0800
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Keith:
Thanks for pointing this out and I will go with this in my implementation.

I think, the 2nd paragraph in "Overview of operation" in the draft should be
reworded.
It says,
----------------------------------------------------------------------------
---------
This extension has the property that it works even when only one UA
   in a dialog supports it. The processing steps differ for handling
   each of the four cases (UAC supports it, or doesn't, and UAS supports
   it, or doesn't).
----------------------------------------------------------------------------
--------

Doesn't this mean even if UAC does not support timer, UAS could support it?

Veda


----- Original Message -----
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Veda Hegde'" <vhegde@san.rr.com>; "Paul Kyzivat" <pkyzivat@cisco.com>;
"Rosen Brian" <Brian.Rosen@marconi.com>
Cc: <sip@ietf.org>
Sent: Monday, December 01, 2003 10:41 AM
Subject: RE: [Sip] Session timer question


> I think this is answered by subclause 8.2.4 of RFC 3261, viz:
>
> 8.2.4 Applying Extensions
>
>    A UAS that wishes to apply some extension when generating the
>    response MUST NOT do so unless support for that extension is
>    indicated in the Supported header field in the request.  If the
>    desired extension is not supported, the server SHOULD rely only on
>    baseline SIP and any other extensions supported by the client.  In
>    rare circumstances, where the server cannot process the request
>    without the extension, the server MAY send a 421 (Extension Required)
>    response.  This response indicates that the proper response cannot be
>    generated without support of a specific extension.  The needed
>    extension(s) MUST be included in a Require header field in the
>    response.  This behavior is NOT RECOMMENDED, as it will generally
>    break interoperability.
>
>    Any extensions applied to a non-421 response MUST be listed in a
>    Require header field included in the response.  Of course, the server
>    MUST NOT apply extensions not listed in the Supported header field in
>    the request.  As a result of this, the Require header field in a
>    response will only ever contain option tags defined in standards-
>    track RFCs.
>
> regards
>
> Keith
>
> > -----Original Message-----
> > From: Veda Hegde [mailto:vhegde@san.rr.com]
> > Sent: 01 December 2003 18:27
> > To: Paul Kyzivat; Rosen Brian
> > Cc: sip@ietf.org
> > Subject: Re: [Sip] Session timer question
> >
> >
> > Hi:
> > I don't think it says in the draft that a proxy/UAS can not
> > put Require:
> > timer in 2xx, if UAC did not include Supported: timer in the request.
> > May be this should be specified in the draft.
> > Veda
> >
> >
> > ----- Original Message -----
> > From: "Paul Kyzivat" <pkyzivat@cisco.com>
> > To: "Rosen, Brian" <Brian.Rosen@marconi.com>
> > Cc: <vhegde@san.rr.com>; <sip@ietf.org>
> > Sent: Monday, December 01, 2003 7:36 AM
> > Subject: Re: [Sip] Session timer question
> >
> >
> > > Brian,
> > >
> > > The question was about a Require in a 200 response to an
> > invite. The UAC
> > > clearly can't return a 420 in that case.
> > >
> > > I don't think any valid usage of session timer will ever
> > result in this
> > > case. The only cases where Require: timer is validly put into the
> > > response are when the request contained Supported: timer.
> > >
> > > So this can only result from a broken proxy or UAS. In this
> > case I think
> > > the UAC is justified in either sending an ACK and then BYE as you
> > > suggest, or else just ignoring the Required: timer.
> > >
> > > Paul
> > >
> > > Rosen, Brian wrote:
> > > > You send 420  - Bad Extension, because you don't understand the
> > > > timer option in the Require.  See section 8.2.2.3 in RFC3261.
> > > >
> > > > Brian
> > > > -----Original Message-----
> > > > From: vhegde@san.rr.com [mailto:vhegde@san.rr.com]
> > > > Sent: Friday, November 28, 2003 9:13 PM
> > > > To: sip@ietf.org
> > > > Subject: [Sip] Session timer question
> > > >
> > > >
> > > > Hi:
> > > > I have a question on session timer message flow.
> > > >
> > > >  If a UA does not support session timer and if it receives
> > > >
> > > > Require: timer
> > > > Session Expires: 3600
> > > >
> > > > in the 200 OK to re-INVITE what is the correct way to process this
> > response?
> > > >
> > > >
> > > > Should UAC Ack the 200 OK and then send a bye or ignore
> > the Require and
> > > > session Expires: headers and continue with rest of the processing?
> > > >
> > > > Veda
> > > >
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Dec  2 03:28:39 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08052
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 03:28:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR5tN-0002Bp-8X
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 03:28:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB28SLxI008416
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 03:28:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR5t4-0002Ar-Qd; Tue, 02 Dec 2003 03:28:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR5sp-0002A1-Fe
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 03:27:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08035
	for <sip@ietf.org>; Tue, 2 Dec 2003 03:27:34 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AR5sn-0003Ok-00
	for sip@ietf.org; Tue, 02 Dec 2003 03:27:45 -0500
Received: from web12705.mail.yahoo.com ([216.136.173.242])
	by ietf-mx with smtp (Exim 4.12)
	id 1AR5sm-0003Oh-00
	for sip@ietf.org; Tue, 02 Dec 2003 03:27:44 -0500
Message-ID: <20031202082745.37337.qmail@web12705.mail.yahoo.com>
Received: from [128.107.253.44] by web12705.mail.yahoo.com via HTTP; Tue, 02 Dec 2003 00:27:45 PST
Date: Tue, 2 Dec 2003 00:27:45 -0800 (PST)
From: Gokul Krishnan <gktvm2@yahoo.com>
Subject: Re: [Sip] Query on Extensions
To: pkyzivat@cisco.com
Cc: sip@ietf.org
In-Reply-To: <3FCB7F39.6090205@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1386608887-1070353665=:36198"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0-1386608887-1070353665=:36198
Content-Type: text/plain; charset=us-ascii

Thanks for the reply Paul.
 
Suppose I add a new method to SIP, say REMOVEPARTY. Now,
(1) if my UAC want to force this on UAS, is the only way to define a package, say pRem, and use "Require: pRem" ??
(2) if my UAC want just to let know the UAS, should I use "Supported: pRem" ? 
Can I only use "Allow: REMOVEPARTY" in Case2 ?


Paul Kyzivat <pkyzivat@cisco.com> wrote:


Gokul Krishnan wrote:
> Hi All,
> 
> What is the difference between "Allow" and "Supported" header *from a 
> usage perspective*?
> 
> As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and 
> for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).

"Allow" identifies sip *methods* that the UA supports. "Supported" 
identifies named "packages" that the UA supports. The values are drawn 
from different namespaces.

> What is the advantage/disadvantage of each approach?

They aren't substitutes for one another. A package listed as Supported 
may require the use of certain methods. Those methods should also be 
listed in an Allow header.

An example of this is 100rel. You need to specify both Allow: UPDATE and 
Supported: 100rel to use reliable provisional responses.

Paul


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


---------------------------------
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
--0-1386608887-1070353665=:36198
Content-Type: text/html; charset=us-ascii

<DIV><FONT face=verdana color=#0000ff>Thanks for the reply Paul.</FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#0000ff>Suppose I add a new method to SIP, say REMOVEPARTY. Now,</FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff>(1) if my UAC&nbsp;want to force this on UAS, is the only way to define a package, say pRem,&nbsp;and use "Require: pRem" ??</FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff>(2) if my UAC&nbsp;want just to&nbsp;let know&nbsp;the UAS, should I use "Supported: pRem" ? </FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff>Can&nbsp;I&nbsp;only use&nbsp;"Allow: REMOVEPARTY"&nbsp;in Case2 ?</FONT></DIV>
<DIV><BR><BR><B><I>Paul Kyzivat &lt;pkyzivat@cisco.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR><BR>Gokul Krishnan wrote:<BR>&gt; Hi All,<BR>&gt; <BR>&gt; What is the difference between "Allow" and "Supported" header *from a <BR>&gt; usage perspective*?<BR>&gt; <BR>&gt; As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and <BR>&gt; for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).<BR><BR>"Allow" identifies sip *methods* that the UA supports. "Supported" <BR>identifies named "packages" that the UA supports. The values are drawn <BR>from different namespaces.<BR><BR>&gt; What is the advantage/disadvantage of each approach?<BR><BR>They aren't substitutes for one another. A package listed as Supported <BR>may require the use of certain methods. Those methods should also be <BR>listed in an Allow header.<BR><BR>An example of this is 100rel. You need to specify both Allow: UPDATE and <BR>Supported: 100rel to use reliable provisional
 responses.<BR><BR>Paul<BR><BR><BR>_______________________________________________<BR>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>This list is for NEW development of the core SIP Protocol<BR>Use sip-implementors@cs.columbia.edu for questions on current sip<BR>Use sipping@ietf.org for new developments on the application of sip<BR></BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/">Free Pop-Up Blocker - Get it now</a>
--0-1386608887-1070353665=:36198--

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



From exim@www1.ietf.org  Tue Dec  2 05:42:31 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11351
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 05:42:31 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR7yx-0000B0-2S
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 05:42:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2AgFjl000674
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 05:42:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR7yj-00006r-MX; Tue, 02 Dec 2003 05:42:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR7xs-00005f-0c
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 05:41:08 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11264
	for <sip@ietf.org>; Tue, 2 Dec 2003 05:40:53 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AR7xo-0004k3-00
	for sip@ietf.org; Tue, 02 Dec 2003 05:41:04 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AR7xn-0004k0-00
	for sip@ietf.org; Tue, 02 Dec 2003 05:41:03 -0500
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB2Af3s29898
	for <sip@ietf.org>; Tue, 2 Dec 2003 12:41:03 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T66435d7763ac158f24060@esvir04nok.ntc.nokia.com>;
 Tue, 2 Dec 2003 12:41:03 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 2 Dec 2003 12:41:02 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 2 Dec 2003 12:41:02 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3B8C0.C7AB676C"
Subject: RE: [Sip] Query on Extensions
Date: Tue, 2 Dec 2003 12:41:01 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B115@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] Query on Extensions
Thread-Index: AcO4shJ4kiw6YumtThOtm0kZKao90gADgdRQ
To: <gktvm2@yahoo.com>, <pkyzivat@cisco.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 02 Dec 2003 10:41:02.0663 (UTC) FILETIME=[C8161D70:01C3B8C0]
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

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

If you put Allow: REMOVEPARTY, you are telling the other side that you =
can handle a request with method REMOVEPARTY if you receive it. You tell =
the other side what methods you support. Require-header tells the other =
side that if it doesn't support a certain extension, then you don't want =
to talk to it.
=20
So if you require the other side to support REMOVEPARTY, then you would =
have the require: pRem extension.
=20
/Hisham

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext =
Gokul Krishnan
Sent: 02.December.2003 10:28
To: pkyzivat@cisco.com
Cc: sip@ietf.org
Subject: Re: [Sip] Query on Extensions


Thanks for the reply Paul.
=20
Suppose I add a new method to SIP, say REMOVEPARTY. Now,
(1) if my UAC want to force this on UAS, is the only way to define a =
package, say pRem, and use "Require: pRem" ??
(2) if my UAC want just to let know the UAS, should I use "Supported: =
pRem" ?=20
Can I only use "Allow: REMOVEPARTY" in Case2 ?


Paul Kyzivat <pkyzivat@cisco.com> wrote:



Gokul Krishnan wrote:
> Hi All,
>=20
> What is the difference between "Allow" and "Supported" header *from a=20
> usage perspective*?
>=20
> As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and=20
> for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).

"Allow" identifies sip *methods* that the UA supports. "Supported"=20
identifies named "packages" that the UA supports. The values are drawn=20
from different namespaces.

> What is the advantage/disadvantage of each approach?

They aren't substitutes for one another. A package listed as Supported=20
may require the use of certain methods. Those methods should also be=20
listed in an Allow header.

An example of this is 100rel. You need to specify both Allow: UPDATE and =

Supported: 100rel to use reliable provisional responses.

Paul


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




  _____ =20

Do you Yahoo!?
Free  <http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/> =
Pop-Up Blocker - Get it now


------_=_NextPart_001_01C3B8C0.C7AB676C
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">


<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D271103610-02122003><FONT face=3DArial color=3D#0000ff =
size=3D2>If you=20
put Allow: REMOVEPARTY, you are telling the other side that you can =
handle a=20
request with method REMOVEPARTY if you receive it. You tell the other =
side what=20
methods you support. Require-header tells the other side that if it =
doesn't=20
support a certain extension, then you don't want to talk to=20
it.</FONT></SPAN></DIV>
<DIV><SPAN class=3D271103610-02122003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D271103610-02122003><FONT face=3DArial color=3D#0000ff =
size=3D2>So if=20
you require the other side to support REMOVEPARTY, then you would have =
the=20
require: pRem extension.</FONT></SPAN></DIV>
<DIV><SPAN class=3D271103610-02122003><FONT face=3DArial color=3D#0000ff =

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

size=3D2>/Hisham</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> sip-admin@ietf.org =

  [mailto:sip-admin@ietf.org]<B>On Behalf Of </B>ext Gokul=20
  Krishnan<BR><B>Sent:</B> 02.December.2003 10:28<BR><B>To:</B>=20
  pkyzivat@cisco.com<BR><B>Cc:</B> sip@ietf.org<BR><B>Subject:</B> Re: =
[Sip]=20
  Query on Extensions<BR><BR></FONT></DIV>
  <DIV><FONT face=3Dverdana color=3D#0000ff>Thanks for the reply =
Paul.</FONT></DIV>
  <DIV><FONT face=3DVerdana color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DVerdana color=3D#0000ff>Suppose I add a new method =
to SIP, say=20
  REMOVEPARTY. Now,</FONT></DIV>
  <DIV><FONT face=3DVerdana color=3D#0000ff>(1) if my UAC&nbsp;want to =
force this on=20
  UAS, is the only way to define a package, say pRem,&nbsp;and use =
"Require:=20
  pRem" ??</FONT></DIV>
  <DIV><FONT face=3DVerdana color=3D#0000ff>(2) if my UAC&nbsp;want just =
to&nbsp;let=20
  know&nbsp;the UAS, should I use "Supported: pRem" ? </FONT></DIV>
  <DIV><FONT face=3DVerdana color=3D#0000ff>Can&nbsp;I&nbsp;only =
use&nbsp;"Allow:=20
  REMOVEPARTY"&nbsp;in Case2 ?</FONT></DIV>
  <DIV><BR><BR><B><I>Paul Kyzivat &lt;pkyzivat@cisco.com&gt;</I></B>=20
wrote:</DIV>
  <BLOCKQUOTE class=3Dreplbq=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px =
solid"><BR><BR>Gokul=20
    Krishnan wrote:<BR>&gt; Hi All,<BR>&gt; <BR>&gt; What is the =
difference=20
    between "Allow" and "Supported" header *from a <BR>&gt; usage=20
    perspective*?<BR>&gt; <BR>&gt; As an example, for PRACK an UAC sends =

    Supported:100rel (RFC 3262) and <BR>&gt; for UPDATE, the UAC is =
supposed to=20
    send Allow: UPDATE (RFC 3311).<BR><BR>"Allow" identifies sip =
*methods* that=20
    the UA supports. "Supported" <BR>identifies named "packages" that =
the UA=20
    supports. The values are drawn <BR>from different =
namespaces.<BR><BR>&gt;=20
    What is the advantage/disadvantage of each approach?<BR><BR>They =
aren't=20
    substitutes for one another. A package listed as Supported <BR>may =
require=20
    the use of certain methods. Those methods should also be <BR>listed =
in an=20
    Allow header.<BR><BR>An example of this is 100rel. You need to =
specify both=20
    Allow: UPDATE and <BR>Supported: 100rel to use reliable provisional=20
    =
responses.<BR><BR>Paul<BR><BR><BR>_______________________________________=
________<BR>Sip=20
    mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>This list =
is for=20
    NEW development of the core SIP Protocol<BR>Use=20
    sip-implementors@cs.columbia.edu for questions on current sip<BR>Use =

    sipping@ietf.org for new developments on the application of=20
  sip<BR></BLOCKQUOTE>
  <P>
  <HR SIZE=3D1>
  Do you Yahoo!?<BR><A=20
  =
href=3D"http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/">=
Free=20
  Pop-Up Blocker - Get it now</A></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3B8C0.C7AB676C--

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



From exim@www1.ietf.org  Tue Dec  2 07:46:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14756
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 07:46:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR9uz-0005hl-5w
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 07:46:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2CkHX5021926
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 07:46:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR9ul-0005go-4Z; Tue, 02 Dec 2003 07:46:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AR9uf-0005gJ-Bb
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 07:45:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14724
	for <sip@ietf.org>; Tue, 2 Dec 2003 07:45:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AR9ue-0006c8-00
	for sip@ietf.org; Tue, 02 Dec 2003 07:45:56 -0500
Received: from web12701.mail.yahoo.com ([216.136.173.238])
	by ietf-mx with smtp (Exim 4.12)
	id 1AR9ud-0006c3-00
	for sip@ietf.org; Tue, 02 Dec 2003 07:45:55 -0500
Message-ID: <20031202124554.56726.qmail@web12701.mail.yahoo.com>
Received: from [128.107.253.44] by web12701.mail.yahoo.com via HTTP; Tue, 02 Dec 2003 04:45:54 PST
Date: Tue, 2 Dec 2003 04:45:54 -0800 (PST)
From: Gokul Krishnan <gktvm2@yahoo.com>
Subject: RE: [Sip] Query on Extensions
To: hisham.khartabil@nokia.com
Cc: sip@ietf.org
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B115@esebe019.ntc.nokia.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1595446770-1070369154=:52677"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0-1595446770-1070369154=:52677
Content-Type: text/plain; charset=us-ascii

Thanks Hisham.
 
But this is what confuses me: 
 
By using "Require" we force the other side to support the extension.
 
By using "Supported" or "Allow" we are letting the other side know that we support some (new) extension - by using a token (in case of "Supported") or by using method name itself (in case of "Allow"). When implementing a new methd (not forcing the other side) why should I go for "Supported"? Cant I just settle with "Allow" ? 
 
Or is it that even with "Require", we must send "Allow" also ?! Which will mean that, if "Require" or "Supported" is there, then it must be accompanied with "Allow"?
 
Sorry for keeping on bombarding with the same query, but I am confused :(


hisham.khartabil@nokia.com wrote:
If you put Allow: REMOVEPARTY, you are telling the other side that you can handle a request with method REMOVEPARTY if you receive it. You tell the other side what methods you support. Require-header tells the other side that if it doesn't support a certain extension, then you don't want to talk to it.
 
So if you require the other side to support REMOVEPARTY, then you would have the require: pRem extension.
 
/Hisham
-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext Gokul Krishnan
Sent: 02.December.2003 10:28
To: pkyzivat@cisco.com
Cc: sip@ietf.org
Subject: Re: [Sip] Query on Extensions


Thanks for the reply Paul.
 
Suppose I add a new method to SIP, say REMOVEPARTY. Now,
(1) if my UAC want to force this on UAS, is the only way to define a package, say pRem, and use "Require: pRem" ??
(2) if my UAC want just to let know the UAS, should I use "Supported: pRem" ? 
Can I only use "Allow: REMOVEPARTY" in Case2 ?


Paul Kyzivat <pkyzivat@cisco.com> wrote:


Gokul Krishnan wrote:
> Hi All,
> 
> What is the difference between "Allow" and "Supported" header *from a 
> usage perspective*?
> 
> As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and 
> for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).

"Allow" identifies sip *methods* that the UA supports. "Supported" 
identifies named "packages" that the UA supports. The values are drawn 
from different namespaces.

> What is the advantage/disadvantage of each approach?

They aren't substitutes for one another. A package listed as Supported 
may require the use of certain methods. Those methods should also be 
listed in an Allow header.

An example of this is 100rel. You need to specify both Allow: UPDATE and 
Supported: 100rel to use reliable provisional responses.

Paul


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


---------------------------------
Do you Yahoo!?
Free Pop-Up Blocker - Get it now

---------------------------------
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
--0-1595446770-1070369154=:52677
Content-Type: text/html; charset=us-ascii

<DIV><FONT face=verdana color=#0000ff>Thanks Hisham.</FONT></DIV>
<DIV><FONT face=verdana color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=verdana color=#0000ff>But this is what confuses me: </FONT></DIV>
<DIV><FONT face=verdana color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=verdana color=#0000ff>By using "Require"&nbsp;we <STRONG>force</STRONG> the other side to support the extension.</FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=verdana color=#0000ff>By using "Supported" or "Allow" we are letting the other side know that we support some (new)&nbsp;extension - by using a token (in case of "Supported") or by using method name itself (in case of "Allow"). When&nbsp;implementing a new methd (not forcing the other side) why should I go for "Supported"? Cant I just settle with "Allow" ? </FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#0000ff>Or is it that even with "Require", we must send "Allow" also ?! Which will mean that, if "Require" or "Supported" is there, then&nbsp;it must&nbsp;be accompanied with "Allow"?</FONT></DIV>
<DIV><FONT face=verdana color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=verdana color=#0000ff>Sorry for keeping on bombarding with the same query, but I am confused :(</FONT></DIV>
<DIV><BR><BR><B><I>hisham.khartabil@nokia.com</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<META content="MSHTML 6.00.2800.1276" name=GENERATOR>
<DIV><SPAN class=271103610-02122003><FONT face=Arial color=#0000ff size=2>If you put Allow: REMOVEPARTY, you are telling the other side that you can handle a request with method REMOVEPARTY if you receive it. You tell the other side what methods you support. Require-header tells the other side that if it doesn't support a certain extension, then you don't want to talk to it.</FONT></SPAN></DIV>
<DIV><SPAN class=271103610-02122003><FONT face=Arial color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=271103610-02122003><FONT face=Arial color=#0000ff size=2>So if you require the other side to support REMOVEPARTY, then you would have the require: pRem extension.</FONT></SPAN></DIV>
<DIV><SPAN class=271103610-02122003><FONT face=Arial color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=271103610-02122003><FONT face=Arial color=#0000ff size=2>/Hisham</FONT></SPAN></DIV>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> sip-admin@ietf.org [mailto:sip-admin@ietf.org]<B>On Behalf Of </B>ext Gokul Krishnan<BR><B>Sent:</B> 02.December.2003 10:28<BR><B>To:</B> pkyzivat@cisco.com<BR><B>Cc:</B> sip@ietf.org<BR><B>Subject:</B> Re: [Sip] Query on Extensions<BR><BR></FONT></DIV>
<DIV><FONT face=verdana color=#0000ff>Thanks for the reply Paul.</FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#0000ff>Suppose I add a new method to SIP, say REMOVEPARTY. Now,</FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff>(1) if my UAC&nbsp;want to force this on UAS, is the only way to define a package, say pRem,&nbsp;and use "Require: pRem" ??</FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff>(2) if my UAC&nbsp;want just to&nbsp;let know&nbsp;the UAS, should I use "Supported: pRem" ? </FONT></DIV>
<DIV><FONT face=Verdana color=#0000ff>Can&nbsp;I&nbsp;only use&nbsp;"Allow: REMOVEPARTY"&nbsp;in Case2 ?</FONT></DIV>
<DIV><BR><BR><B><I>Paul Kyzivat &lt;pkyzivat@cisco.com&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid"><BR><BR>Gokul Krishnan wrote:<BR>&gt; Hi All,<BR>&gt; <BR>&gt; What is the difference between "Allow" and "Supported" header *from a <BR>&gt; usage perspective*?<BR>&gt; <BR>&gt; As an example, for PRACK an UAC sends Supported:100rel (RFC 3262) and <BR>&gt; for UPDATE, the UAC is supposed to send Allow: UPDATE (RFC 3311).<BR><BR>"Allow" identifies sip *methods* that the UA supports. "Supported" <BR>identifies named "packages" that the UA supports. The values are drawn <BR>from different namespaces.<BR><BR>&gt; What is the advantage/disadvantage of each approach?<BR><BR>They aren't substitutes for one another. A package listed as Supported <BR>may require the use of certain methods. Those methods should also be <BR>listed in an Allow header.<BR><BR>An example of this is 100rel. You need to specify both Allow: UPDATE and <BR>Supported: 100rel to use reliable provisional
 responses.<BR><BR>Paul<BR><BR><BR>_______________________________________________<BR>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip<BR>This list is for NEW development of the core SIP Protocol<BR>Use sip-implementors@cs.columbia.edu for questions on current sip<BR>Use sipping@ietf.org for new developments on the application of sip<BR></BLOCKQUOTE>
<P>
<HR SIZE=1>
Do you Yahoo!?<BR><A href="http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/">Free Pop-Up Blocker - Get it now</A></BLOCKQUOTE></BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://us.rd.yahoo.com/slv/mailtag/*http://companion.yahoo.com/">Free Pop-Up Blocker - Get it now</a>
--0-1595446770-1070369154=:52677--

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



From exim@www1.ietf.org  Tue Dec  2 11:39:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25779
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 11:39:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDYN-0008Tc-1k
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 11:39:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GdAYw032578
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 11:39:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDXJ-0008Ha-39; Tue, 02 Dec 2003 11:38:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDWb-00087o-67
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 11:37:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25580
	for <sip@ietf.org>; Tue, 2 Dec 2003 11:37:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARDWa-0003jo-00
	for sip@ietf.org; Tue, 02 Dec 2003 11:37:20 -0500
Received: from central.switch.ch ([130.59.11.11])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARDWZ-0003jR-00
	for sip@ietf.org; Tue, 02 Dec 2003 11:37:19 -0500
Received: from machb.switch.ch ([130.59.6.129])
	by central.switch.ch with esmtp (Exim 3.20 #1)
	id 1ARDW4-0003Ac-00; Tue, 02 Dec 2003 17:36:48 +0100
Date: Tue, 2 Dec 2003 17:36:48 +0100 (CET)
From: Bernie Hoeneisen <bhoeneis@switch.ch>
To: "'Rene Bartsch'" <ml@bartschnet.de>
cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: RE: [Sip] ENUM-support in SIP-protocol?
In-Reply-To: <A9DECB0B8A01A54DBECC03B25D29513CD564BC@stntexch03.va.neustar.com>
Message-ID: <Pine.OSX.4.58.0312021730250.18789@machb.switch.ch>
References: <A9DECB0B8A01A54DBECC03B25D29513CD564BC@stntexch03.va.neustar.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi Rene!

The below might also be of interest for you.

cheers,
 Bernie

---

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Telephone Number Mapping Working Group of
the IETF.

        Title           : enumservice registration for SIP Addresses-of-Record
        Author(s)       : J. Peterson
        Filename        : draft-ietf-enum-sip-01.txt
        Pages           : 9
        Date            : 2003-12-1

This document registers an ENUM service for SIP (the Session
Initiation Protocol), pursuant to the guidelines in RFC2916bis.
Specifically, this document focuses on provisioning SIP addresses-of-
record in ENUM.

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

[...]

----

On Mon, 1 Dec 2003, Peterson, Jon wrote:

>
> See:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sipping-e164-04.txt
>
> Jon Peterson
> NeuStar, Inc.
>
> > -----Original Message-----
> > From: Rene Bartsch [mailto:ml@bartschnet.de]
> > Sent: Saturday, November 29, 2003 11:26 AM
> > To: sip@ietf.org
> > Subject: [Sip] ENUM-support in SIP-protocol?
> >
> >
> > Hi,
> >
> > first I'm new to the list, so hello to all! :-)
> >
> > My question is if there is any draft of plan to implement ENUM-lookups
> > into the SIP-protocol?
> >
> > Rene Bartsch
> >
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Tue Dec  2 12:04:16 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27487
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 12:04:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDwD-00035B-Ul
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 12:03:59 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H3ncf011848
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 12:03:49 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDvf-0002tb-Gs; Tue, 02 Dec 2003 12:03:15 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDtU-0002Lh-4h
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 12:01:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27205
	for <sip@ietf.org>; Tue, 2 Dec 2003 12:00:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARDtI-0004Lt-00
	for sip@ietf.org; Tue, 02 Dec 2003 12:00:48 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARDtI-0004Kr-00
	for sip@ietf.org; Tue, 02 Dec 2003 12:00:48 -0500
Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hB2Gtbg14277;
	Tue, 2 Dec 2003 10:55:49 -0600 (CST)
Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2)
	id hB2GsLD12485; Tue, 2 Dec 2003 10:54:21 -0600 (CST)
Message-ID: <3FCCC3AD.7020607@lucent.com>
Date: Tue, 02 Dec 2003 10:54:05 -0600
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Wireless Networks Research and Development
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rohan Mahy <rohan@cisco.com>, Dean Willis <dean.willis@softarmor.com>,
        SIP LIST <sip@ietf.org>
CC: "Jain, Rajnish" <rajnishjain@xl.com>,
        "Chris Boulton" <cboulton@ubiquity.net>, slawrence@pingtel.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] TCP connection design team?
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Rohan/Dean:

At the Minneapolis IETF last month, we arrived at a consensus on
the SIP WG mailing list [1] that a BCP-type document should be
produced for TCP connections; more specifically, devise and/or
document means to keep TCP connections open for a longer time.
The current crop of servers do not keep connections between
transactions in any deterministic manner.  Furthermore, TCP
connection management is unclear and/or under-specified in
rfc3261.

At the San Francisco IETF (56th IETF, March 2003), I had presented
a draft [2] which extended Rohan's Connection-Reuse draft [3] to
provide for long lived connections and other related aspects.  At
that time, there wasn't sufficient interest to drive the work
beyond what was decribed in [3]; and while I agreed to
produce a BCP, it has not happened yet.

There is now, I believe, more of an interest to move this work
forward.  I've been in touch with the folks CC'd on this email,
all of whom have expressed an interest and willingness to
contribute to this work.  However, I would like to request the
chairs to officially designate a design team for this effort.  We
could always simply "go ahed and do it", but it would help
tremendously to have some official working group recognition of
the effort.  This will attract folks with actual TCP implementations
who have battled the connection reuse and longevity issues.

I would propose using [2,3] as starting points for a BCP.

I look forward to your response.

References:

[1] Thread starting with
http://www1.ietf.org/mail-archive/working-groups/sip/current/msg09007.html
[2] Requirements for persistent connection management in SIP
http://www.ietf.org/internet-drafts/draft-jain-sipping-persistent-conn-reqs-01.txt
[3] Connection reuse in SIP
http://www.ietf.org/internet-drafts/draft-ietf-sip-connect-reuse-00.txt

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 exim@www1.ietf.org  Tue Dec  2 12:04:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27519
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 12:04:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDwW-0003BW-Oq
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 12:04:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2H48Hn012187
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 12:04:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDwS-00039d-OO; Tue, 02 Dec 2003 12:04:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARDwA-00033c-Ea
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 12:03:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27448
	for <sip@ietf.org>; Tue, 2 Dec 2003 12:03:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARDw7-0004Qo-00
	for sip@ietf.org; Tue, 02 Dec 2003 12:03:43 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARDw7-0004QL-00
	for sip@ietf.org; Tue, 02 Dec 2003 12:03:43 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 02 Dec 2003 09:06:08 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB2H39w5009388;
	Tue, 2 Dec 2003 09:03:09 -0800 (PST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEI97664;
	Tue, 2 Dec 2003 12:03:05 -0500 (EST)
Message-ID: <3FCCC5C9.5060109@cisco.com>
Date: Tue, 02 Dec 2003 12:03:05 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gokul Krishnan <gktvm2@yahoo.com>
CC: hisham.khartabil@nokia.com, sip@ietf.org
Subject: Re: [Sip] Query on Extensions
References: <20031202124554.56726.qmail@web12701.mail.yahoo.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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Gokul Krishnan wrote:
> Thanks Hisham.
>  
> But this is what confuses me:
>  
> By using "Require" we *force* the other side to support the extension.
>  
> By using "Supported" or "Allow" we are letting the other side know that 
> we support some (new) extension - by using a token (in case of 
> "Supported") or by using method name itself (in case of "Allow"). 
> When implementing a new methd (not forcing the other side) why should I 
> go for "Supported"? Cant I just settle with "Allow" ?

When implementing a new method, you would probably expose your 
capability with Allow. "Supported" isn't about a specific method, it is 
about some package of functionality. Of course any package of 
functionality is going to need to use some methods, but often it will 
use common methods in special ways.

For example, the "timer" package only requires the use of INVITE and 
ACK, but it also requires the processing of specific extension headers 
and some specific protocol actions.

> Or is it that even with "Require", we must send "Allow" also ?! Which 
> will mean that, if "Require" or "Supported" is there, then it must be 
> accompanied with "Allow"?

Typically yes. If you want to be complete, you will list every supported 
method in Allow, and every supported package in Supported.

> Sorry for keeping on bombarding with the same query, but I am confused :(

Yes, it is a bit obscure.

	Paul


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



From exim@www1.ietf.org  Tue Dec  2 13:36:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01327
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 13:36:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARFNj-0000Iu-3L
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 13:36:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2IaIld001108
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 13:36:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARFNT-0000Gt-6C; Tue, 02 Dec 2003 13:36:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARFN4-0000GI-Go
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 13:35:38 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01204
	for <sip@ietf.org>; Tue, 2 Dec 2003 13:35:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARFN2-0005q3-00
	for sip@ietf.org; Tue, 02 Dec 2003 13:35:36 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARFN1-0005pz-00
	for sip@ietf.org; Tue, 02 Dec 2003 13:35:35 -0500
Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hB2IbDud020682
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Tue, 2 Dec 2003 12:37:13 -0600
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id hB2IbDLW020680;
	Tue, 2 Dec 2003 12:37:13 -0600
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: RE: [Sip] SCTP and TLS
From: Dean Willis <dean.willis@softarmor.com>
To: Adam Roach <adam@dynamicsoft.com>
Cc: "'Vijay K. Gurbani'" <vkg@lucent.com>, Cullen Jennings <fluffy@cisco.com>,
        sip@ietf.org
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86650@dyn-tx-exch-001.dynamicsoft.com>
References: 
	 <9BF66EBF6BEFD942915B4D4D45C051F3E86650@dyn-tx-exch-001.dynamicsoft.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1070390232.20281.46.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Tue, 02 Dec 2003 12:37:12 -0600
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

> However, this leaves the issue of Via headers.
> 
> I can say:
> 
>   Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds
> 
> Or:
> 
>   Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds
> 
> But there is no standardized syntax that allows me to say
> both at the same time.
> 

Record-in, record out. Use two Via header fields, one for each
interface. Just like a dual-homed proxy.

--
Dean

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



From exim@www1.ietf.org  Tue Dec  2 15:37:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09063
	for <sip-archive@odin.ietf.org>; Tue, 2 Dec 2003 15:37:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARHFp-0006rr-RH
	for sip-archive@odin.ietf.org; Tue, 02 Dec 2003 15:36:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KaHJX026334
	for sip-archive@odin.ietf.org; Tue, 2 Dec 2003 15:36:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARHFd-0006pk-39; Tue, 02 Dec 2003 15:36:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARHFN-0006p1-Q9
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 15:35:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08760
	for <sip@ietf.org>; Tue, 2 Dec 2003 15:35:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARHFM-0000Aw-00
	for sip@ietf.org; Tue, 02 Dec 2003 15:35:48 -0500
Received: from mail4.dynamicsoft.com ([63.110.3.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARHFL-0000AX-00
	for sip@ietf.org; Tue, 02 Dec 2003 15:35:47 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hB2KY7ZA022427;
	Tue, 2 Dec 2003 14:34:07 -0600 (CST)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YBTH5WDJ>; Tue, 2 Dec 2003 14:34:07 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86686@dyn-tx-exch-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Dean Willis'" <dean.willis@softarmor.com>,
        Adam Roach
	 <adam@dynamicsoft.com>
Cc: "'Vijay K. Gurbani'" <vkg@lucent.com>,
        Cullen Jennings
	 <fluffy@cisco.com>, sip@ietf.org
Subject: RE: [Sip] SCTP and TLS
Date: Tue, 2 Dec 2003 14:34:06 -0600 
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Dean Willis [mailto:dean.willis@softarmor.com] writes:

> > However, this leaves the issue of Via headers.
> > 
> > I can say:
> > 
> >   Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds
> > 
> > Or:
> > 
> >   Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds
> > 
> > But there is no standardized syntax that allows me to say
> > both at the same time.
> > 
> 
> Record-in, record out. Use two Via header fields, one for each
> interface. Just like a dual-homed proxy.

I think you're confused. I'm talking about the case in which I'm
sending over a TLS connection that rides on top of SCTP, not
bridging between the two kinds of connections (which would require
only one via header, anyway).

/a

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



From exim@www1.ietf.org  Thu Dec  4 15:29:49 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12782
	for <sip-archive@odin.ietf.org>; Thu, 4 Dec 2003 15:29:49 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS06P-0006xG-DX
	for sip-archive@odin.ietf.org; Thu, 04 Dec 2003 15:29:33 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4KTXEQ026674
	for sip-archive@odin.ietf.org; Thu, 4 Dec 2003 15:29:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS05t-0006vF-Sq; Thu, 04 Dec 2003 15:29:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS05Z-0006uv-Rw
	for sip@optimus.ietf.org; Thu, 04 Dec 2003 15:28:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12764
	for <sip@ietf.org>; Thu, 4 Dec 2003 15:28:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS05Y-0007es-00
	for sip@ietf.org; Thu, 04 Dec 2003 15:28:40 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS05X-0007eo-00
	for sip@ietf.org; Thu, 04 Dec 2003 15:28:39 -0500
Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hB4KVSud030535
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <sip@ietf.org>; Thu, 4 Dec 2003 14:31:28 -0600
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id hB4KVScb030533
	for sip@ietf.org; Thu, 4 Dec 2003 14:31:28 -0600
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: VIRUS WARNING: Re: [Sip] Asserted-Identity: How to 'hint'?
From: Dean Willis <dean.willis@softarmor.com>
To: sip@ietf.org
In-Reply-To: <200312032059.hB3KxNRt012161@smtp.hispeed.ch>
References: <200312032059.hB3KxNRt012161@smtp.hispeed.ch>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1070569888.29479.18.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 04 Dec 2003 14:31:28 -0600
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

The original of this message, received by me at 2:59 PM US CST on Dece 3
2003 seems to be carrying a virus payload. More and more clever every
day, the little monsters.

Note that the From address is given as:

Jonathan Rosenberg <jdrosen@DNS2Go.deerfield.com>

which, as we should all know, is not actually Jonathan's address.

On Wed, 2003-12-03 at 14:59, Jonathan Rosenberg wrote:
> inline.
> 
> jh@lohi.eng.song.fi wrote:
> > 
> > Peterson, Jon writes:
> > 
> >  > So, I take it from the silence on this list today about this matter
> > that
> >  > there is consensus to create a P-Suggested-Identity header in the
> >

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



From exim@www1.ietf.org  Thu Dec  4 15:32:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12870
	for <sip-archive@odin.ietf.org>; Thu, 4 Dec 2003 15:32:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS08q-0007Ez-Sa
	for sip-archive@odin.ietf.org; Thu, 04 Dec 2003 15:32:05 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4KW43Y027750
	for sip-archive@odin.ietf.org; Thu, 4 Dec 2003 15:32:04 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS08m-0007Cn-Tn; Thu, 04 Dec 2003 15:32:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AS07s-00076w-Vt
	for sip@optimus.ietf.org; Thu, 04 Dec 2003 15:31:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12822
	for <sip@ietf.org>; Thu, 4 Dec 2003 15:30:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS07r-0007fs-00
	for sip@ietf.org; Thu, 04 Dec 2003 15:31:03 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AS07q-0007fp-00
	for sip@ietf.org; Thu, 04 Dec 2003 15:31:03 -0500
Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1])
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hB4KXcud030546
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 4 Dec 2003 14:33:38 -0600
Received: (from dwillis@localhost)
	by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id hB4KXbr8030544;
	Thu, 4 Dec 2003 14:33:37 -0600
X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f
Subject: RE: [Sip] SCTP and TLS
From: Dean Willis <dean.willis@softarmor.com>
To: Adam Roach <adam@dynamicsoft.com>
Cc: "'Vijay K. Gurbani'" <vkg@lucent.com>, Cullen Jennings <fluffy@cisco.com>,
        sip@ietf.org
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86686@dyn-tx-exch-001.dynamicsoft.com>
References: 
	 <9BF66EBF6BEFD942915B4D4D45C051F3E86686@dyn-tx-exch-001.dynamicsoft.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1070570017.29479.21.camel@bdsl.greycouncil.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 04 Dec 2003 14:33:37 -0600
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On Tue, 2003-12-02 at 14:34, Adam Roach wrote:

Adam said:
> Dea nSaid:
> > Record-in, record out. Use two Via header fields, one for each
> > interface. Just like a dual-homed proxy.
> 
> I think you're confused. I'm talking about the case in which I'm
> sending over a TLS connection that rides on top of SCTP, not
> bridging between the two kinds of connections (which would require
> only one via header, anyway).

ah yes, you're right. However, the bridging case does still have the
reversible-route problem for Path and Service-Route, so double-recording
is still nice to do.

--
Dean

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



From exim@www1.ietf.org  Fri Dec  5 14:55:40 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20868
	for <sip-archive@odin.ietf.org>; Fri, 5 Dec 2003 14:55:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASM2v-0002UD-Sx
	for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 14:55:26 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5JtPPD009498
	for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 14:55:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASM2Y-0002S9-Sb; Fri, 05 Dec 2003 14:55:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASM2O-0002Rj-Sw
	for sip@optimus.ietf.org; Fri, 05 Dec 2003 14:54:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20858
	for <sip@ietf.org>; Fri, 5 Dec 2003 14:54:36 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASM2M-0000m1-00
	for sip@ietf.org; Fri, 05 Dec 2003 14:54:50 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASM2L-0000lY-00
	for sip@ietf.org; Fri, 05 Dec 2003 14:54:49 -0500
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5Js1ca027525;
	Fri, 5 Dec 2003 14:54:01 -0500 (EST)
Message-ID: <3FD0E253.1000401@dynamicsoft.com>
Date: Fri, 05 Dec 2003 14:53:55 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Tolga Asveren <asveren@ulticom.com>, sip@ietf.org
Subject: Re: [Sip] remote terget update
References: <GBEBKGPKHGPAOFCLBNAMEEIMCCAA.asveren@ulticom.com> <3FCB6090.2060004@cisco.com>
In-Reply-To: <3FCB6090.2060004@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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

In particular, see:

> 8.2 UAS Behavior
> 
>    When a request outside of a dialog is processed by a UAS, there is a
>    set of processing rules that are followed, independent of the method.
>    Section 12 gives guidance on how a UAS can tell whether a request is
>    inside or outside of a dialog.
> 
>    Note that request processing is atomic.  If a request is accepted,
>    all state changes associated with it MUST be performed.  If it is
>    rejected, all state changes MUST NOT be performed.

Thanks,
Jonathan R.

Paul Kyzivat wrote:

> 
> 
> Tolga Asveren wrote:
> 
>> (due to no response in sip-implementors list switching to sip list)
>>  
>> If a reINVITE with target refresh rejected, should remote target 
>> reverted back to its original value before that reINVITE is received?
> 
> 
> Yes, 3261 seems pretty clear on this.
> 
>     Paul
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Fri Dec  5 15:03:26 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21365
	for <sip-archive@odin.ietf.org>; Fri, 5 Dec 2003 15:03:26 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMAR-0002pG-Dc
	for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 15:03:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5K3BEd010856
	for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 15:03:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMAH-0002oD-Nq; Fri, 05 Dec 2003 15:03:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASM9J-0002nd-Cb
	for sip@optimus.ietf.org; Fri, 05 Dec 2003 15:02:01 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21300
	for <sip@ietf.org>; Fri, 5 Dec 2003 15:01:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASM9G-0000we-00
	for sip@ietf.org; Fri, 05 Dec 2003 15:01:58 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASM9F-0000ue-00
	for sip@ietf.org; Fri, 05 Dec 2003 15:01:57 -0500
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5K1Kca027538;
	Fri, 5 Dec 2003 15:01:21 -0500 (EST)
Message-ID: <3FD0E40A.7020008@dynamicsoft.com>
Date: Fri, 05 Dec 2003 15:01:14 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Veda Hegde <vhegde@san.rr.com>
CC: "Drage Keith (Keith)" <drage@lucent.com>,
        Paul Kyzivat <pkyzivat@cisco.com>,
        Rosen Brian <Brian.Rosen@marconi.com>, sip@ietf.org
Subject: Re: [Sip] Session timer question
References: <475FF955A05DD411980D00508B6D5FB00439EF42@en0033exch001u.uk.lucent.com> <001001c3b841$b5c99d60$2506c042@WXPvhegde>
In-Reply-To: <001001c3b841$b5c99d60$2506c042@WXPvhegde>
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

inline.

Veda Hegde wrote:

> Keith: Thanks for pointing this out and I will go with this in my
> implementation.
> 
> I think, the 2nd paragraph in "Overview of operation" in the draft
> should be reworded. It says, 
> ----------------------------------------------------------------------------
>  --------- This extension has the property that it works even when
> only one UA in a dialog supports it. The processing steps differ
> for handling each of the four cases (UAC supports it, or doesn't,
> and UAS supports it, or doesn't). 
> ----------------------------------------------------------------------------
>  --------
> 
> Doesn't this mean even if UAC does not support timer, UAS could
> support it?

Yes, and this mode is supported. In such a case, the INVITE from the 
UAC would lack a Supported header field. Proxies insert 
Session-Expires headers. The UAS receives it. Based on table 2 in the 
session timer spec, since the UAS supports the extension, it sets the 
refresher parameter to "uas", and generates a 2xx with the final 
session timer in the session expires header. This header is ignored by 
the UAC. The called party will generate refresh requests for the 
remainder of the call.

Note that there is no Require in the 2xx in this case.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Fri Dec  5 15:55:41 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26347
	for <sip-archive@odin.ietf.org>; Fri, 5 Dec 2003 15:55:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMyz-00056b-8U
	for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 15:55:25 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5KtPsO019565
	for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 15:55:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMyd-00054H-Rx; Fri, 05 Dec 2003 15:55:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASMxr-0004yn-N8
	for sip@optimus.ietf.org; Fri, 05 Dec 2003 15:54:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26192
	for <sip@ietf.org>; Fri, 5 Dec 2003 15:54:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMxq-0002KL-00
	for sip@ietf.org; Fri, 05 Dec 2003 15:54:14 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASMxp-0002Je-00
	for sip@ietf.org; Fri, 05 Dec 2003 15:54:13 -0500
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5Kreca027580;
	Fri, 5 Dec 2003 15:53:43 -0500 (EST)
Message-ID: <3FD0F04E.9000207@dynamicsoft.com>
Date: Fri, 05 Dec 2003 15:53:34 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hu Yijun,BISC R&D SA(BJ)" <Yijun.Hu@BISC.SIEMENS.COM.CN>
CC: "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] a question about offer/answer model
References: <31F31018FE2DC941A70BD30477510B0C19D53A@biscm02>
In-Reply-To: <31F31018FE2DC941A70BD30477510B0C19D53A@biscm02>
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Setting port numbers to zero rejects a STREAM, not the call per se. As 
such, there would be no bye, the call just proceeds without that 
stream. If none of the streams are acceptable, the answerer would 
reject the invite.

-Jonathan R.

Hu Yijun,BISC R&D SA(BJ) wrote:

> hi all,
>  
> I have a question about the SDP offer/answer model.
>  
> In the section 6 of rfc3264, it claimed that the answerer can reject an 
> offer stream by setting the port number to zero.
>  
> My question is: if an SDP offer, included in INVITE, is reject by the 
> answerer, and the corresponding SDP answer is included in 200 OK, then 
> how to deal with this answer in the offerer(UAC)? Should the UAC treat 
> it as a successful SDP negotiation, or send a BYE immediately after 
> sending the ACK?
> 
> -----------------------------------------------------------------------------
> Best regards,
> Hu Yijun
> BISC, R&D SA
> Tel.:+86-10-64346-660
> E-mail: yijun.hu@bisc.siemens.com.cn
> 
>  

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Fri Dec  5 16:01:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26571
	for <sip-archive@odin.ietf.org>; Fri, 5 Dec 2003 16:01:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASN4V-0005eg-M4
	for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 16:01:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5L17dr021709
	for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 16:01:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASN4R-0005dE-DH; Fri, 05 Dec 2003 16:01:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASN3w-0005bG-5x
	for sip@optimus.ietf.org; Fri, 05 Dec 2003 16:00:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26510
	for <sip@ietf.org>; Fri, 5 Dec 2003 16:00:16 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASN3u-0002Rx-00
	for sip@ietf.org; Fri, 05 Dec 2003 16:00:30 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASN3t-0002R7-00
	for sip@ietf.org; Fri, 05 Dec 2003 16:00:29 -0500
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5L03ca027584;
	Fri, 5 Dec 2003 16:00:04 -0500 (EST)
Message-ID: <3FD0F1CD.4020208@dynamicsoft.com>
Date: Fri, 05 Dec 2003 15:59:57 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: sip@ietf.org
Subject: Re: [Sip] Entity-tags in PUBLISH
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D917F@esebe013.ntc.nokia.com>
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D917F@esebe013.ntc.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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Once the syntax and semantics are not the same, you should not use the 
same header name. Even if we added back in the features we don't need 
pper se, there is still the issue of SHOULD vs. MUST for etag 
inclusion in the response. I think we definitely want a must. Thus, 
this is a change in behavior from HTTP.

I would propose we use "SIP-Etag" and "SIP-If-Match" to convey that 
these are similar in scope to their http bretheren, but not the same.

-Jonathan R.

aki.niemi@nokia.com wrote:

> Hi,
> 
> As we discussed in Minneapolis, the PUBLISH draft needs additional text covering the use of etags, and the relationship to HTTP in this respect. One related thing that came up was that although the etags in PUBLISH have been copied from RFC 2616, there are some minor differences, mainly due to the fact that with PUBLISH, we don't have use for features used with for example the GET and HEAD methods:
> 
>    - We have dropped the weak etag concept, because PUBLISH etags are basically 
>      always strong. As a side effect, the syntax is also different, i.e., an etag 
>      is a token, instead of quoted-string with an optional "weakness" tag prefix. 
>      This seemed reasonable, since this is the common way to representing	
>      similar things in SIP, and after removing the weak tag, the quotes were 
>      superfluous.
> 
>    - We have dropped multiple etags in If-Match header, because in PUBLISH, the 
>      EPA will always only modify/remove/refresh its own publications. This 
>      corresponds to a conditional PUT in HTTP/1.1, where only a single entity-tag 
>      is present in If-Match.
> 
>    - We have dropped the "*" valued If-Match. An "If-Match: *" corresponds to a 
>      PUBLISH without the If-Match header, so there is no need for this special 
>      value.
> 
>    - In HTTP/1.1, the origin server SHOULD create an etag, whereas in PUBLISH, 
>      the ESC MUST always create an etag.
> 
> The main functionality of etags is the same in my opinion, even with the above "focused" use of them. But I would still like some input on whether the working group feels these differences are considerable enough that we should *not* inherit the syntax for these headers from HTTP/1.1, but create similar but distinct header field names, and response code.
> 
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Fri Dec  5 16:06:22 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26730
	for <sip-archive@odin.ietf.org>; Fri, 5 Dec 2003 16:06:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASN9L-0005vK-AF
	for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 16:06:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5L67R8022744
	for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 16:06:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASN9H-0005u0-Oy; Fri, 05 Dec 2003 16:06:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASN8v-0005tT-Kg
	for sip@optimus.ietf.org; Fri, 05 Dec 2003 16:05:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26701
	for <sip@ietf.org>; Fri, 5 Dec 2003 16:05:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASN8t-0002Wh-00
	for sip@ietf.org; Fri, 05 Dec 2003 16:05:40 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASN8t-0002WS-00
	for sip@ietf.org; Fri, 05 Dec 2003 16:05:39 -0500
Received: from rtp-core-2.cisco.com (64.102.124.13)
  by sj-iport-5.cisco.com with ESMTP; 05 Dec 2003 21:05:13 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB5L55DM025839;
	Fri, 5 Dec 2003 16:05:06 -0500 (EST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEL68926;
	Fri, 5 Dec 2003 16:05:04 -0500 (EST)
Message-ID: <3FD0F300.70502@cisco.com>
Date: Fri, 05 Dec 2003 16:05:04 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "Hu Yijun,BISC R&D SA(BJ)" <Yijun.Hu@BISC.SIEMENS.COM.CN>,
        "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] a question about offer/answer model
References: <31F31018FE2DC941A70BD30477510B0C19D53A@biscm02> <3FD0F04E.9000207@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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:
> Setting port numbers to zero rejects a STREAM, not the call per se. As 
> such, there would be no bye, the call just proceeds without that stream. 
> If none of the streams are acceptable, the answerer would reject the 
> invite.

Of course an answerer *could* reject all the streams without rejecting 
the call. This would leave a medialess call. Certainly not a common 
situation, but possible.

The answerer might do that with the thought of initiating a new 
offer/answer that it thinks might be more acceptable.

In such a situation, the initial offerer has multiple possibilities:
- send a BYE to terminate the dialog
- send a new offer (via reINVITE or UPDATE) and hope things go
   better
- just wait with no media and see what happens.

A UA like a phone, that sees this entire possibility as remote and to be 
avoided, should probably just be prepared to send a BYE in this case.

	Paul


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



From exim@www1.ietf.org  Fri Dec  5 16:59:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28625
	for <sip-archive@odin.ietf.org>; Fri, 5 Dec 2003 16:59:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASNyp-0007u9-2Q
	for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 16:59:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5LxIx6030325
	for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 16:59:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASNyX-0007sG-OS; Fri, 05 Dec 2003 16:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASNyR-0007rs-LJ
	for sip@optimus.ietf.org; Fri, 05 Dec 2003 16:58:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28594
	for <sip@ietf.org>; Fri, 5 Dec 2003 16:58:38 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASNyO-0007YK-00
	for sip@ietf.org; Fri, 05 Dec 2003 16:58:52 -0500
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASNyN-0007XK-00
	for sip@ietf.org; Fri, 05 Dec 2003 16:58:51 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hB5Lvvd08451;
	Fri, 5 Dec 2003 15:58:03 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip-implementors@cs.columbia.edu, sip@ietf.org
Content-Type: text/plain
Message-Id: <1070661467.911.30.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Fri, 05 Dec 2003 15:57:47 -0600
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] SIPIT 14 Registration
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

SIPIT 14 Registration is open.

The event will be held  9-February through 13-February 2004.

The last day to register is 16-January-2004
(The last day to secure a room at the event is 9-January-2004)

If you plan to attend, but have not already registered, please do
so soon.

Registration information is available at:
http://www.etsi.org/plugtests/SIPIT14.htm	

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 exim@www1.ietf.org  Fri Dec  5 17:22:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29709
	for <sip-archive@odin.ietf.org>; Fri, 5 Dec 2003 17:22:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASOKz-0000eK-0k
	for sip-archive@odin.ietf.org; Fri, 05 Dec 2003 17:22:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5MMC1C002495
	for sip-archive@odin.ietf.org; Fri, 5 Dec 2003 17:22:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASOKn-0000bs-KD; Fri, 05 Dec 2003 17:22:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASOJt-0000aw-O7
	for sip@optimus.ietf.org; Fri, 05 Dec 2003 17:21:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29677
	for <sip@ietf.org>; Fri, 5 Dec 2003 17:20:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASOJr-0002vl-00
	for sip@ietf.org; Fri, 05 Dec 2003 17:21:03 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASOJq-0002rR-00
	for sip@ietf.org; Fri, 05 Dec 2003 17:21:02 -0500
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB5MKcca027601
	for <sip@ietf.org>; Fri, 5 Dec 2003 17:20:38 -0500 (EST)
Message-ID: <3FD104AF.2030505@dynamicsoft.com>
Date: Fri, 05 Dec 2003 17:20:31 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Updated gruu mechanism spec
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Folks,

Based on discussions during the IETF 58 meeting, I've submitted a 
revision to the gruu mechanism document. Until it appears in the 
archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt

The changes are as follows:

* clarified that the registrar needs to return the same gruu in 
registration refreshes, and this requires reliable storage. No 
requirement for returning the same gruu across registrations.

* clarified that the registrar should ignore any gruu parameter 
provided in the contact header fields of a registration

* mention that, it is still possible that a gruu changes in a 
registration, in the case where there is a race condition where the 
client thinks its refreshing, but the registration has just expired at 
the registrar. As such, recommend that a UA be prepared to deal with 
such a change.

* removed text about using this mechanism to replace dialog reuse

* added some more details on the encryption mechanism, such as 
recommended algorithm and key lengths. Also clearly state that this is 
just one way to do it, you can do it statefully if you want.

* proxies are prohibited from redirecting a request to a gruu, they 
have to proxy it. If they redirect, you'll ruin any nat traversal 
benefits associated with gruus.

* clarified that gruus don't provide sufficient privacy services, and 
added a reference to the privacy spec

* removed the notion of locally generated gruus. The text now says you 
need to use the registration mechanism in the draft to obtain a gruu. 
The result is the end of e2e signaling. It also mentions that a new 
specification is forthcoming which will address this limitation.


At this point, there are no known open issues. I would like to see if 
there is consensus to adopt this item as a work item of the sip 
working group. I do not believe we took such a poll during the 
meeting. Chairs - can you assist?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Sat Dec  6 06:08:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05598
	for <sip-archive@odin.ietf.org>; Sat, 6 Dec 2003 06:08:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASaIP-0005e2-Rb
	for sip-archive@odin.ietf.org; Sat, 06 Dec 2003 06:08:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB6B8L3M021638
	for sip-archive@odin.ietf.org; Sat, 6 Dec 2003 06:08:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASaI5-0005c3-1t; Sat, 06 Dec 2003 06:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASaI0-0005bo-GI
	for sip@optimus.ietf.org; Sat, 06 Dec 2003 06:07:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05582
	for <sip@ietf.org>; Sat, 6 Dec 2003 06:07:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASaHw-0006Oo-00
	for sip@ietf.org; Sat, 06 Dec 2003 06:07:52 -0500
Received: from web12704.mail.yahoo.com ([216.136.173.241])
	by ietf-mx with smtp (Exim 4.12)
	id 1ASaHw-0006Ol-00
	for sip@ietf.org; Sat, 06 Dec 2003 06:07:52 -0500
Message-ID: <20031206110753.51440.qmail@web12704.mail.yahoo.com>
Received: from [128.107.253.44] by web12704.mail.yahoo.com via HTTP; Sat, 06 Dec 2003 03:07:53 PST
Date: Sat, 6 Dec 2003 03:07:53 -0800 (PST)
From: Gokul Krishnan <gktvm2@yahoo.com>
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-2047766205-1070708873=:50009"
Subject: [Sip] Encryption in SIP
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--0-2047766205-1070708873=:50009
Content-Type: text/plain; charset=us-ascii

Hi All,
 
A query on Encryption in SIP.
 
How is end-to-end encryption achieved in SIP? RFC2543 had headers - Encryption and Response-Key. But in RFC3261 I could only see the mentioning about hop-by-hop encryption using TL/IPSec. Please point to me to the correct portion of RFC in case I am missing something.
 
Thanks
Gokul


---------------------------------
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing
--0-2047766205-1070708873=:50009
Content-Type: text/html; charset=us-ascii

<DIV><FONT face=verdana color=#800000>Hi All,</FONT></DIV>
<DIV><FONT face=Verdana color=#800000></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#800000>A query on Encryption in SIP.</FONT></DIV>
<DIV><FONT face=Verdana color=#800000></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#800000>How is <STRONG>end-to-end encryption</STRONG> achieved in SIP? RFC2543 had headers - Encryption and Response-Key. But in RFC3261 I could only see the mentioning about hop-by-hop encryption using TL/IPSec. Please point to me to the correct portion of RFC&nbsp;in case&nbsp;I am missing something.</FONT></DIV>
<DIV><FONT face=Verdana color=#800000></FONT>&nbsp;</DIV>
<DIV><FONT face=Verdana color=#800000>Thanks</FONT></DIV>
<DIV><FONT face=Verdana color=#800000>Gokul</FONT></DIV><p><hr SIZE=1>
Do you Yahoo!?<br>
<a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=21260/*http://photos.yahoo.com">New Yahoo! Photos - easier uploading and sharing</a>
--0-2047766205-1070708873=:50009--

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



From exim@www1.ietf.org  Sat Dec  6 12:16:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14008
	for <sip-archive@odin.ietf.org>; Sat, 6 Dec 2003 12:16:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASg2Q-0008Jz-Sr
	for sip-archive@odin.ietf.org; Sat, 06 Dec 2003 12:16:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB6HGEUJ031928
	for sip-archive@odin.ietf.org; Sat, 6 Dec 2003 12:16:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASg2F-0008IN-Au; Sat, 06 Dec 2003 12:16:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASg1t-0008Hl-IQ
	for sip@optimus.ietf.org; Sat, 06 Dec 2003 12:15:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14002
	for <sip@ietf.org>; Sat, 6 Dec 2003 12:15:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASg1s-0003zf-00
	for sip@ietf.org; Sat, 06 Dec 2003 12:15:40 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASg1r-0003zF-00
	for sip@ietf.org; Sat, 06 Dec 2003 12:15:39 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 06 Dec 2003 09:16:31 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB6HF7At008769;
	Sat, 6 Dec 2003 09:15:08 -0800 (PST)
Received: from [142.131.37.127] (sjc-vpn4-75.cisco.com [10.21.80.75])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AKN41686;
	Sat, 6 Dec 2003 09:15:06 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sat, 06 Dec 2003 09:15:05 -0800
From: Cullen Jennings <fluffy@cisco.com>
To: <sip@ietf.org>
CC: <aki.niemi@nokia.com>
Message-ID: <BBF74E99.283D8%fluffy@cisco.com>
In-Reply-To: <E1AHqa6-0007Dk-Cl@asgard.ietf.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Contact header in PUBLISH
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Right now the draft says "The PUBLISH request MUST NOT contain a Contact
header." 

Why? Does it do any harm? The paragraph before this makes if fairly clear
that PUBLISH does create a new Dialog.

The AIB strongly encourages including the Contact header in the sipfrag as
correlating material. Clearly we want to use the AIB with PUBLISH. Don't
know if this really helps the AIB stuff or not.

Anyways, I understand why the Contact header doesn't mean much in a PUBLISH.
I don't understand why such strong MUST NOT language.


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 exim@www1.ietf.org  Sat Dec  6 22:17:48 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29661
	for <sip-archive@odin.ietf.org>; Sat, 6 Dec 2003 22:17:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASpQJ-0007mk-O3
	for sip-archive@odin.ietf.org; Sat, 06 Dec 2003 22:17:33 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB73HVPM029867
	for sip-archive@odin.ietf.org; Sat, 6 Dec 2003 22:17:31 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASpPp-0007kq-TR; Sat, 06 Dec 2003 22:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASpPk-0007kV-MY
	for sip@optimus.ietf.org; Sat, 06 Dec 2003 22:16:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29647
	for <sip@ietf.org>; Sat, 6 Dec 2003 22:16:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASpPh-0003D9-00
	for sip@ietf.org; Sat, 06 Dec 2003 22:16:53 -0500
Received: from dnsmx1pya.telcordia.com ([128.96.20.31])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ASpPh-0003Bv-00
	for sip@ietf.org; Sat, 06 Dec 2003 22:16:53 -0500
Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78])
	by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id hB73GLg01675
	for <sip@ietf.org>; Sat, 6 Dec 2003 22:16:21 -0500 (EST)
Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61])
 by rrc-its-ieg01.cc.telcordia.com (SAVSMTP 3.1.2.35) with SMTP id M2003120622162223018
 for <sip@ietf.org>; Sat, 06 Dec 2003 22:16:22 -0500
Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72)
	id <X4S5WAJQ>; Sat, 6 Dec 2003 22:16:22 -0500
Message-ID: <7B762A7337179544B02B707FAC7F6F1903C9900B@rrc-its-exs03.mail.saic.com>
From: "Song, Youngsun" <ysong@telcordia.com>
To: "'sip@ietf.org '" <sip@ietf.org>
Date: Sat, 6 Dec 2003 22:15:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] text/plain content type for non-ascii char
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi, 

(I didn't get any response in sip-implementer email list, so i am posting
this here...sorry for cross-posting.)

Based on RFC2046, the charset parameter of the "text/plain" content-type 
seems to only support US-ASCII or ISO-8859-X. 
For carrying an instant message using SIP MESSAGE, does this mean that 
non-ascii characters (double-byte characters) can't be sent using the 
"text/plain" content-type? 

Thanks, 
YoungSun 


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



From exim@www1.ietf.org  Sun Dec  7 04:49:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18491
	for <sip-archive@odin.ietf.org>; Sun, 7 Dec 2003 04:49:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASvXS-0005hi-0q
	for sip-archive@odin.ietf.org; Sun, 07 Dec 2003 04:49:20 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB79nHWJ021866
	for sip-archive@odin.ietf.org; Sun, 7 Dec 2003 04:49:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ASvXC-0005fh-JQ; Sun, 07 Dec 2003 04:49:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ARENm-0006M0-EX
	for sip@optimus.ietf.org; Tue, 02 Dec 2003 12:32:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29106
	for <sip@ietf.org>; Tue, 2 Dec 2003 12:32:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARENk-000544-00
	for sip@ietf.org; Tue, 02 Dec 2003 12:32:16 -0500
Received: from mx4.ust.hk ([143.89.13.26])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ARENi-000541-00
	for sip@ietf.org; Tue, 02 Dec 2003 12:32:15 -0500
Received: from dngdesk (cm61-10-150-38.hkcable.com.hk [61.10.150.38])
	(authenticated bits=0)
	by mx4.ust.hk (8.12.10/8.12.10) with ESMTP id hB2HW8L1083725
	for <sip@ietf.org>; Wed, 3 Dec 2003 01:32:09 +0800 (HKT)
Message-ID: <005101c3b8fa$332f0480$0100a8c0@dngdesk>
From: "Denon@UST" <denon@ust.hk>
To: <sip@ietf.org>
Subject: [SIP] Where can I find Internet draft for SIP Billing?
Date: Wed, 3 Dec 2003 01:32:02 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_004E_01C3B93D.4095D250"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_004E_01C3B93D.4095D250
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Where can I find Internet draft for SIP Billing?
And I also want to find information about the difficulity of of SIP =
billing development
Thanks a lot

------=_NextPart_000_004E_01C3B93D.4095D250
Content-Type: text/html;
	charset="big5"
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=3Dbig5">
<META content=3D"MSHTML 6.00.2800.1264" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Where can I find Internet draft for SIP =

Billing?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>And I also want to find information =
about the=20
difficulity of of SIP billing development</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks a lot</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_004E_01C3B93D.4095D250--


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



From exim@www1.ietf.org  Sun Dec  7 10:14:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25774
	for <sip-archive@odin.ietf.org>; Sun, 7 Dec 2003 10:14:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT0bs-0007Oi-HA
	for sip-archive@odin.ietf.org; Sun, 07 Dec 2003 10:14:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7FECA3028432
	for sip-archive@odin.ietf.org; Sun, 7 Dec 2003 10:14:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT0bh-0007NW-Fi; Sun, 07 Dec 2003 10:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AT0bU-0007N6-KH
	for sip@optimus.ietf.org; Sun, 07 Dec 2003 10:13:48 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25688
	for <sip@ietf.org>; Sun, 7 Dec 2003 10:13:33 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT0bS-00020g-00
	for sip@ietf.org; Sun, 07 Dec 2003 10:13:46 -0500
Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AT0bR-00020d-00
	for sip@ietf.org; Sun, 07 Dec 2003 10:13:45 -0500
Received: from sip ([218.106.195.96])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hB7FCok5022845;
	Sun, 7 Dec 2003 16:13:38 +0100 (MET)
From: "Christian Stredicke" <stredicke@snom.de>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: AW: [Sip] Updated gruu mechanism spec
Date: Sun, 7 Dec 2003 23:12:51 +0800
Message-ID: <000f01c3bcd4$b39f3530$60fd340a@sip>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <3FD104AF.2030505@dynamicsoft.com>
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi Jonathan,

I think we should add to the draft that the user agent which registers
using gruu and TCP must not close its TCP connection at least until the
registration expires (also the server must not close this connection,
but I think that=92s clear). This would be an important clarification on
the TCP stuff which has recently been discussed.

If that desire should be programmable (to limit the number of concurrent
TCP connections on the server), then we must include a hint for the user
agent on how to behave. But surely the default behavior should be the
above.

Christian

> -----Urspr=FCngliche Nachricht-----
> Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
> Jonathan Rosenberg
> Gesendet: Freitag, 5. Dezember 2003 23:21
> An: sip@ietf.org
> Betreff: [Sip] Updated gruu mechanism spec
>=20
> Folks,
>=20
> Based on discussions during the IETF 58 meeting, I've submitted a
> revision to the gruu mechanism document. Until it appears in the
> archives, you can pick up a copy at:
>=20
> http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt
>=20
> The changes are as follows:
>=20
> * clarified that the registrar needs to return the same gruu in
> registration refreshes, and this requires reliable storage. No
> requirement for returning the same gruu across registrations.
>=20
> * clarified that the registrar should ignore any gruu parameter
> provided in the contact header fields of a registration
>=20
> * mention that, it is still possible that a gruu changes in a
> registration, in the case where there is a race condition where the
> client thinks its refreshing, but the registration has just expired at
> the registrar. As such, recommend that a UA be prepared to deal with
> such a change.
>=20
> * removed text about using this mechanism to replace dialog reuse
>=20
> * added some more details on the encryption mechanism, such as
> recommended algorithm and key lengths. Also clearly state that this is
> just one way to do it, you can do it statefully if you want.
>=20
> * proxies are prohibited from redirecting a request to a gruu, they
> have to proxy it. If they redirect, you'll ruin any nat traversal
> benefits associated with gruus.
>=20
> * clarified that gruus don't provide sufficient privacy services, and
> added a reference to the privacy spec
>=20
> * removed the notion of locally generated gruus. The text now says you
> need to use the registration mechanism in the draft to obtain a gruu.
> The result is the end of e2e signaling. It also mentions that a new
> specification is forthcoming which will address this limitation.
>=20
>=20
> At this point, there are no known open issues. I would like to see if
> there is consensus to adopt this item as a work item of the sip
> working group. I do not believe we took such a poll during the
> meeting. Chairs - can you assist?
>=20
> Thanks,
> Jonathan R.
>=20
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


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



From exim@www1.ietf.org  Mon Dec  8 04:17:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02027
	for <sip-archive@odin.ietf.org>; Mon, 8 Dec 2003 04:17:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATHW2-0005Oa-Ge
	for sip-archive@odin.ietf.org; Mon, 08 Dec 2003 04:17:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB89HI8H020736
	for sip-archive@odin.ietf.org; Mon, 8 Dec 2003 04:17:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATHVn-0005Nb-1M; Mon, 08 Dec 2003 04:17:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATHVh-0005Mv-Tv
	for sip@optimus.ietf.org; Mon, 08 Dec 2003 04:16:58 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02022
	for <sip@ietf.org>; Mon, 8 Dec 2003 04:16:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATHVf-0007OK-00
	for sip@ietf.org; Mon, 08 Dec 2003 04:16:55 -0500
Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly05a.srv.mailcontrol.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATHVe-0007Ny-00
	for sip@ietf.org; Mon, 08 Dec 2003 04:16:54 -0500
Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by rly05a.srv.mailcontrol.com (MailControl) with SMTP id hB89G8dR022074;
	Mon, 8 Dec 2003 09:16:08 GMT
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Mon, 8 Dec 2003 09:18:41 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Updated gruu mechanism spec
Date: Mon, 8 Dec 2003 09:16:08 -0000
Message-ID: <45730E094814E44488F789C1CDED27AE01E22F19@gbnewp0758m.eu.ubiquity.net>
Thread-Topic: [Sip] Updated gruu mechanism spec
Thread-Index: AcO81McIxVTbhBnHTWyK2zd7WxoJnQAlu1QA
From: "Chris Boulton" <cboulton@ubiquity.net>
To: "Christian Stredicke" <stredicke@snom.de>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com)
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Christian,
	I agree BUT isn't this a more generalized recommendation for UA's using TC=
P.  Maybe this type of information would be better suited in a generic TCP =
usage doc.

Chris.


>-----Original Message-----
>From: Christian Stredicke [mailto:stredicke@snom.de]
>Sent: 07 December 2003 15:13
>To: 'Jonathan Rosenberg'
>Cc: sip@ietf.org
>Subject: AW: [Sip] Updated gruu mechanism spec
>
>Hi Jonathan,
>
>I think we should add to the draft that the user agent which registers
>using gruu and TCP must not close its TCP connection at least until the
>registration expires (also the server must not close this connection,
>but I think that's clear). This would be an important clarification on
>the TCP stuff which has recently been discussed.
>
>If that desire should be programmable (to limit the number of concurrent
>TCP connections on the server), then we must include a hint for the user
>agent on how to behave. But surely the default behavior should be the
>above.
>
>Christian
>
>> -----Urspr=FCngliche Nachricht-----
>> Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
>> Jonathan Rosenberg
>> Gesendet: Freitag, 5. Dezember 2003 23:21
>> An: sip@ietf.org
>> Betreff: [Sip] Updated gruu mechanism spec
>>
>> Folks,
>>
>> Based on discussions during the IETF 58 meeting, I've submitted a
>> revision to the gruu mechanism document. Until it appears in the
>> archives, you can pick up a copy at:
>>
>> http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt
>>
>> The changes are as follows:
>>
>> * clarified that the registrar needs to return the same gruu in
>> registration refreshes, and this requires reliable storage. No
>> requirement for returning the same gruu across registrations.
>>
>> * clarified that the registrar should ignore any gruu parameter
>> provided in the contact header fields of a registration
>>
>> * mention that, it is still possible that a gruu changes in a
>> registration, in the case where there is a race condition where the
>> client thinks its refreshing, but the registration has just expired at
>> the registrar. As such, recommend that a UA be prepared to deal with
>> such a change.
>>
>> * removed text about using this mechanism to replace dialog reuse
>>
>> * added some more details on the encryption mechanism, such as
>> recommended algorithm and key lengths. Also clearly state that this is
>> just one way to do it, you can do it statefully if you want.
>>
>> * proxies are prohibited from redirecting a request to a gruu, they
>> have to proxy it. If they redirect, you'll ruin any nat traversal
>> benefits associated with gruus.
>>
>> * clarified that gruus don't provide sufficient privacy services, and
>> added a reference to the privacy spec
>>
>> * removed the notion of locally generated gruus. The text now says you
>> need to use the registration mechanism in the draft to obtain a gruu.
>> The result is the end of e2e signaling. It also mentions that a new
>> specification is forthcoming which will address this limitation.
>>
>>
>> At this point, there are no known open issues. I would like to see if
>> there is consensus to adopt this item as a work item of the sip
>> working group. I do not believe we took such a poll during the
>> meeting. Chairs - can you assist?
>>
>> Thanks,
>> Jonathan R.
>>
>> --
>> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>> Chief Technology Officer                    Parsippany, NJ 07054-2711
>> dynamicsoft
>> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>> http://www.jdrosen.net                      PHONE: (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
>
>________________________________________________________________________
>This email has been scanned for all viruses by the MessageLabs Email
>Security System. For more information on a proactive email security
>service working around the clock, around the globe, visit
>http://www.messagelabs.com
>________________________________________________________________________


This message has been scanned for viruses by MailControl - www.mailcontrol.=
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 exim@www1.ietf.org  Mon Dec  8 04:29:33 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02356
	for <sip-archive@odin.ietf.org>; Mon, 8 Dec 2003 04:29:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATHhe-0005xp-PZ
	for sip-archive@odin.ietf.org; Mon, 08 Dec 2003 04:29:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB89TId6022695
	for sip-archive@odin.ietf.org; Mon, 8 Dec 2003 04:29:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATHhP-0005oz-Ej; Mon, 08 Dec 2003 04:29:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATHgq-0005nW-Tx
	for sip@optimus.ietf.org; Mon, 08 Dec 2003 04:28:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02300
	for <sip@ietf.org>; Mon, 8 Dec 2003 04:28:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATHgn-0007WF-00
	for sip@ietf.org; Mon, 08 Dec 2003 04:28:25 -0500
Received: from natsmtp01.rzone.de ([81.169.145.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATHgn-0007WC-00
	for sip@ietf.org; Mon, 08 Dec 2003 04:28:25 -0500
Received: from sip ([61.235.251.68])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hB89S1m4024983;
	Mon, 8 Dec 2003 10:28:02 +0100 (MET)
From: "Christian Stredicke" <stredicke@snom.de>
To: "'Chris Boulton'" <cboulton@ubiquity.net>
Cc: <sip@ietf.org>, "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Subject: AW: [Sip] Updated gruu mechanism spec
Date: Mon, 8 Dec 2003 17:28:03 +0800
Message-ID: <008301c3bd6d$969296a0$60fd340a@sip>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <45730E094814E44488F789C1CDED27AE01E22F19@gbnewp0758m.eu.ubiquity.net>
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi Chris,

well usually it is a good idea for the UAC to close the TCP connection
in order to keep the load on the server low. But in the specific case of
obtaining a GRUU (behind NAT) this is not a good practice; therefore I
think it fits well into the GRUU draft.

Christian

> -----Urspr=FCngliche Nachricht-----
> Von: Chris Boulton [mailto:cboulton@ubiquity.net]
> Gesendet: Montag, 8. Dezember 2003 17:16
> An: Christian Stredicke; Jonathan Rosenberg
> Cc: sip@ietf.org
> Betreff: RE: [Sip] Updated gruu mechanism spec
>=20
> Christian,
> 	I agree BUT isn't this a more generalized recommendation for
UA's
> using TCP.  Maybe this type of information would be better suited in a
> generic TCP usage doc.
>=20
> Chris.
>=20
>=20
> >-----Original Message-----
> >From: Christian Stredicke [mailto:stredicke@snom.de]
> >Sent: 07 December 2003 15:13
> >To: 'Jonathan Rosenberg'
> >Cc: sip@ietf.org
> >Subject: AW: [Sip] Updated gruu mechanism spec
> >
> >Hi Jonathan,
> >
> >I think we should add to the draft that the user agent which
registers
> >using gruu and TCP must not close its TCP connection at least until
the
> >registration expires (also the server must not close this connection,
> >but I think that's clear). This would be an important clarification
on
> >the TCP stuff which has recently been discussed.
> >
> >If that desire should be programmable (to limit the number of
concurrent
> >TCP connections on the server), then we must include a hint for the
user
> >agent on how to behave. But surely the default behavior should be the
> >above.
> >
> >Christian
> >
> >> -----Urspr=FCngliche Nachricht-----
> >> Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
> >> Jonathan Rosenberg
> >> Gesendet: Freitag, 5. Dezember 2003 23:21
> >> An: sip@ietf.org
> >> Betreff: [Sip] Updated gruu mechanism spec
> >>
> >> Folks,
> >>
> >> Based on discussions during the IETF 58 meeting, I've submitted a
> >> revision to the gruu mechanism document. Until it appears in the
> >> archives, you can pick up a copy at:
> >>
> >> http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt
> >>
> >> The changes are as follows:
> >>
> >> * clarified that the registrar needs to return the same gruu in
> >> registration refreshes, and this requires reliable storage. No
> >> requirement for returning the same gruu across registrations.
> >>
> >> * clarified that the registrar should ignore any gruu parameter
> >> provided in the contact header fields of a registration
> >>
> >> * mention that, it is still possible that a gruu changes in a
> >> registration, in the case where there is a race condition where the
> >> client thinks its refreshing, but the registration has just expired
at
> >> the registrar. As such, recommend that a UA be prepared to deal
with
> >> such a change.
> >>
> >> * removed text about using this mechanism to replace dialog reuse
> >>
> >> * added some more details on the encryption mechanism, such as
> >> recommended algorithm and key lengths. Also clearly state that this
is
> >> just one way to do it, you can do it statefully if you want.
> >>
> >> * proxies are prohibited from redirecting a request to a gruu, they
> >> have to proxy it. If they redirect, you'll ruin any nat traversal
> >> benefits associated with gruus.
> >>
> >> * clarified that gruus don't provide sufficient privacy services,
and
> >> added a reference to the privacy spec
> >>
> >> * removed the notion of locally generated gruus. The text now says
you
> >> need to use the registration mechanism in the draft to obtain a
gruu.
> >> The result is the end of e2e signaling. It also mentions that a new
> >> specification is forthcoming which will address this limitation.
> >>
> >>
> >> At this point, there are no known open issues. I would like to see
if
> >> there is consensus to adopt this item as a work item of the sip
> >> working group. I do not believe we took such a poll during the
> >> meeting. Chairs - can you assist?
> >>
> >> Thanks,
> >> Jonathan R.
> >>
> >> --
> >> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> >> Chief Technology Officer                    Parsippany, NJ
07054-2711
> >> dynamicsoft
> >> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> >> http://www.jdrosen.net                      PHONE: (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
> >
>
>_______________________________________________________________________
_
> >This email has been scanned for all viruses by the MessageLabs Email
> >Security System. For more information on a proactive email security
> >service working around the clock, around the globe, visit
> >http://www.messagelabs.com
>
>_______________________________________________________________________
_
>=20
>=20
> This message has been scanned for viruses by MailControl -
> www.mailcontrol.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 exim@www1.ietf.org  Mon Dec  8 15:05:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27623
	for <sip-archive@odin.ietf.org>; Mon, 8 Dec 2003 15:05:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATRd3-0002HS-Sr
	for sip-archive@odin.ietf.org; Mon, 08 Dec 2003 15:05:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8K5Dl2008762
	for sip-archive@odin.ietf.org; Mon, 8 Dec 2003 15:05:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATRcs-0002Fg-BG; Mon, 08 Dec 2003 15:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATRbw-0002Ds-S2
	for sip@optimus.ietf.org; Mon, 08 Dec 2003 15:04:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27442
	for <sip@ietf.org>; Mon, 8 Dec 2003 15:03:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATRbt-0003qM-00
	for sip@ietf.org; Mon, 08 Dec 2003 15:04:01 -0500
Received: from pine.neustar.com ([209.173.57.70])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATRbt-0003pv-00
	for sip@ietf.org; Mon, 08 Dec 2003 15:04:01 -0500
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11])
	by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hB8K3Ub9025398;
	Mon, 8 Dec 2003 20:03:30 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19)
	id <WAAQ1100>; Mon, 8 Dec 2003 15:03:29 -0500
Message-ID: <A9DECB0B8A01A54DBECC03B25D29513CD564E0@stntexch03.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: "'Gokul Krishnan'" <gktvm2@yahoo.com>, sip@ietf.org
Subject: RE: [Sip] Encryption in SIP
Date: Mon, 8 Dec 2003 15:03:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BDC6.5851DC80"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

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_01C3BDC6.5851DC80
Content-Type: text/plain;
	charset="iso-8859-1"

 
See RFC3261 Section 23, especially 23.4.1 and 23.4.3.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Gokul Krishnan [mailto:gktvm2@yahoo.com]
Sent: Saturday, December 06, 2003 3:08 AM
To: sip@ietf.org
Subject: [Sip] Encryption in SIP


Hi All,
 
A query on Encryption in SIP.
 
How is end-to-end encryption achieved in SIP? RFC2543 had headers -
Encryption and Response-Key. But in RFC3261 I could only see the mentioning
about hop-by-hop encryption using TL/IPSec. Please point to me to the
correct portion of RFC in case I am missing something.
 
Thanks
Gokul



   _____  

Do you Yahoo!?
New
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=21260/*http://photos.yahoo.
com> Yahoo! Photos - easier uploading and sharing


------_=_NextPart_001_01C3BDC6.5851DC80
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 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=605000120-08122003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=605000120-08122003>See 
RFC3261 Section 23, especially 23.4.1 and 23.4.3.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=605000120-08122003><FONT face=Arial color=#0000ff size=2>Jon 
Peterson</FONT></SPAN></DIV>
<DIV><SPAN class=605000120-08122003><FONT face=Arial color=#0000ff 
size=2>NeuStar, Inc.</FONT></SPAN></DIV>
<BLOCKQUOTE 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gokul Krishnan 
  [mailto:gktvm2@yahoo.com]<BR><B>Sent:</B> Saturday, December 06, 2003 3:08 
  AM<BR><B>To:</B> sip@ietf.org<BR><B>Subject:</B> [Sip] Encryption in 
  SIP<BR><BR></FONT></DIV>
  <DIV><FONT face=verdana color=#800000>Hi All,</FONT></DIV>
  <DIV><FONT face=Verdana color=#800000></FONT>&nbsp;</DIV>
  <DIV><FONT face=Verdana color=#800000>A query on Encryption in 
  SIP.</FONT></DIV>
  <DIV><FONT face=Verdana color=#800000></FONT>&nbsp;</DIV>
  <DIV><FONT face=Verdana color=#800000>How is <STRONG>end-to-end 
  encryption</STRONG> achieved in SIP? RFC2543 had headers - Encryption and 
  Response-Key. But in RFC3261 I could only see the mentioning about hop-by-hop 
  encryption using TL/IPSec. Please point to me to the correct portion of 
  RFC&nbsp;in case&nbsp;I am missing something.</FONT></DIV>
  <DIV><FONT face=Verdana color=#800000></FONT>&nbsp;</DIV>
  <DIV><FONT face=Verdana color=#800000>Thanks</FONT></DIV>
  <DIV><FONT face=Verdana color=#800000>Gokul</FONT></DIV>
  <P>
  <HR SIZE=1>
  Do you Yahoo!?<BR><A 
  href="http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=21260/*http://photos.yahoo.com">New 
  Yahoo! Photos - easier uploading and sharing</A></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3BDC6.5851DC80--

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



From exim@www1.ietf.org  Mon Dec  8 17:20:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07207
	for <sip-archive@odin.ietf.org>; Mon, 8 Dec 2003 17:20:32 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTjm-00084k-EA
	for sip-archive@odin.ietf.org; Mon, 08 Dec 2003 17:20:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8MKIQn031038
	for sip-archive@odin.ietf.org; Mon, 8 Dec 2003 17:20:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTjY-00083h-7Y; Mon, 08 Dec 2003 17:20:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATTj0-00082r-Hx
	for sip@optimus.ietf.org; Mon, 08 Dec 2003 17:19:32 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07195
	for <sip@ietf.org>; Mon, 8 Dec 2003 17:19:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTit-0007LO-00
	for sip@ietf.org; Mon, 08 Dec 2003 17:19:23 -0500
Received: from clarepost.cgu.edu ([134.173.237.72])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATTiT-0007Kd-00
	for sip@ietf.org; Mon, 08 Dec 2003 17:18:57 -0500
Received: by clarepost.cgu.edu with Internet Mail Service (5.5.2657.72)
	id <XMANB9WT>; Mon, 8 Dec 2003 14:26:32 -0800
Message-ID: <9C6FE1166FC14444811E7AB3B1B6D7E5A35503@clarepost.cgu.edu>
From: Samir Chatterjee <samir.chatterjee@cgu.edu>
To: "'Peterson, Jon'" <jon.peterson@neustar.biz>,
        "'Gokul Krishnan'"
	 <gktvm2@yahoo.com>, sip@ietf.org
Subject: RE: [Sip] Encryption in SIP
Date: Mon, 8 Dec 2003 14:26:32 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3BDDA.55007780"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

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_01C3BDDA.55007780
Content-Type: text/plain

Kind of curious to know if there is any commercial SIP implementation that
does S/MIME ETE encryption of signaling as well as media encryption? Since
these require digital certificates, are they suffering from similar trust
issues of CAs? Are there any self-signed certs being used?

Samir

 

Dr. Samir Chatterjee

School of Information Science

Claremont Graduate University

130 East 9th Street

Claremont, CA 91711

-----Original Message-----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz] 
Sent: Monday, December 08, 2003 12:03 PM
To: 'Gokul Krishnan'; sip@ietf.org
Subject: RE: [Sip] Encryption in SIP

 

 

See RFC3261 Section 23, especially 23.4.1 and 23.4.3.

 

Jon Peterson

NeuStar, Inc.

-----Original Message-----
From: Gokul Krishnan [mailto:gktvm2@yahoo.com]
Sent: Saturday, December 06, 2003 3:08 AM
To: sip@ietf.org
Subject: [Sip] Encryption in SIP

Hi All,

 

A query on Encryption in SIP.

 

How is end-to-end encryption achieved in SIP? RFC2543 had headers -
Encryption and Response-Key. But in RFC3261 I could only see the mentioning
about hop-by-hop encryption using TL/IPSec. Please point to me to the
correct portion of RFC in case I am missing something.

 

Thanks

Gokul


  _____  


Do you Yahoo!?
New
<http://pa.yahoo.com/*http:/us.rd.yahoo.com/evt=21260/*http:/photos.yahoo.co
m>  Yahoo! Photos - easier uploading and sharing


------_=_NextPart_001_01C3BDDA.55007780
Content-Type: text/html
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">


<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Kind of curious to know if there =
is any
commercial SIP implementation that does S/MIME ETE encryption of =
signaling as
well as media encryption? Since these require digital certificates, are =
they
suffering from similar trust issues of CAs? Are there any self-signed =
certs
being used?</span></font></p>

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

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

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Dr. </span></font><font size=3D2 =
color=3Dnavy
 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Samir
 Chatterjee</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>School of Information =
Science</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Claremont Graduate =
University</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>130 East 9th =
Street</span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Claremont, CA =
91711</span></font></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Peterson, Jon
[mailto:jon.peterson@neustar.biz] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> =
</span></font><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>Monday,
 December 08, 2003</span></font><font size=3D2 face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'> </span></font><font
 size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>12:03 =
PM</span></font><font
size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'><br>
<b><span style=3D'font-weight:bold'>To:</span></b> 'Gokul Krishnan'; =
sip@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: [Sip] =
Encryption in
SIP</span></font></p>

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

<div>

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>See RFC3261 =
Section 23,
especially 23.4.1 and 23.4.3.</span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Jon =
Peterson</span></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D2 =
color=3Dblue face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>NeuStar, =
Inc.</span></font></p>

</div>

<blockquote style=3D'border:none;border-left:solid blue =
1.5pt;padding:0in 0in 0in 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal =
style=3D'margin-right:0in;margin-bottom:12.0pt;margin-left:
.5in'><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Gokul Krishnan
[mailto:gktvm2@yahoo.com]<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Saturday, December =
06, 2003
3:08 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> sip@ietf.org<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> [Sip] =
Encryption in SIP</span></font></p>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dmaroon
face=3DVerdana><span =
style=3D'font-size:12.0pt;font-family:Verdana;color:maroon'>Hi
All,</span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dmaroon
face=3DVerdana><span =
style=3D'font-size:12.0pt;font-family:Verdana;color:maroon'>A
query on Encryption in SIP.</span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dmaroon
face=3DVerdana><span =
style=3D'font-size:12.0pt;font-family:Verdana;color:maroon'>How
is <strong><b><font face=3DVerdana><span =
style=3D'font-family:Verdana'>end-to-end
encryption</span></font></b></strong> achieved in SIP? RFC2543 had =
headers -
Encryption and Response-Key. But in RFC3261 I could only see the =
mentioning
about hop-by-hop encryption using TL/IPSec. Please point to me to the =
correct
portion of RFC&nbsp;in case&nbsp;I am missing =
something.</span></font></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dmaroon
face=3DVerdana><span =
style=3D'font-size:12.0pt;font-family:Verdana;color:maroon'>Thanks</span=
></font></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
color=3Dmaroon
face=3DVerdana><span =
style=3D'font-size:12.0pt;font-family:Verdana;color:maroon'>Gokul</span>=
</font></p>

</div>

<div class=3DMsoNormal align=3Dcenter =
style=3D'margin-left:.5in;text-align:center'><font
size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>

<hr size=3D1 width=3D"100%" align=3Dcenter>

</span></font></div>

<p class=3DMsoNormal style=3D'margin-left:.5in'><font size=3D3 =
face=3D"Times New Roman"><span
style=3D'font-size:12.0pt'>Do you Yahoo!?<br>
<a
href=3D"http://pa.yahoo.com/*http:/us.rd.yahoo.com/evt=3D21260/*http:/ph=
otos.yahoo.com">New
Yahoo! Photos - easier uploading and sharing</a></span></font></p>

</blockquote>

</div>

</body>

</html>

------_=_NextPart_001_01C3BDDA.55007780--

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



From exim@www1.ietf.org  Mon Dec  8 19:05:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14455
	for <sip-archive@odin.ietf.org>; Mon, 8 Dec 2003 19:05:24 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATVNI-0004pR-Ss
	for sip-archive@odin.ietf.org; Mon, 08 Dec 2003 19:05:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB905CZf018557
	for sip-archive@odin.ietf.org; Mon, 8 Dec 2003 19:05:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATVNA-0004oq-05; Mon, 08 Dec 2003 19:05:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATVMU-0004o8-DM
	for sip@optimus.ietf.org; Mon, 08 Dec 2003 19:04:22 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14405
	for <sip@ietf.org>; Mon, 8 Dec 2003 19:04:03 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATVMR-0002Qm-00
	for sip@ietf.org; Mon, 08 Dec 2003 19:04:19 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATVMQ-0002QT-00
	for sip@ietf.org; Mon, 08 Dec 2003 19:04:18 -0500
Received: from sj-core-3.cisco.com (171.68.223.137)
  by sj-iport-5.cisco.com with ESMTP; 09 Dec 2003 00:04:33 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hB903krX021796;
	Mon, 8 Dec 2003 16:03:47 -0800 (PST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEN01434;
	Mon, 8 Dec 2003 19:03:45 -0500 (EST)
Message-ID: <3FD51161.3090005@cisco.com>
Date: Mon, 08 Dec 2003 19:03:45 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] GRUU corner cases
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

GRUU is looking pretty good. As I'm reading thru it I am thinking about 
weird corner cases that might be underspecified.

Suppose one UA registers its own contact without requesting a GRUU:

	REGISTER sip:example.com
	To: sip:foo@example.com
	From: sip:foo@example.com
	Expires: 3600
	Contact: sip:xyz@a.example.com
	Call-Id: 111@a.example.com

Then, another UA queries this registration, and then sends its own 
update to it, requesting a gruu:

	REGISTER sip:example.com
	To: sip:foo@example.com
	From: sip:bar@example.com
	Supported: gruu
	Expires: 3600
	Contact: sip:xyz@a.example.com;gruu
	Call-Id: 222@a.example.com

(Assume this is properly authenticated and authorized.) Is this ok?

Then while that registration is still active, suppose there is yet 
another one:

	REGISTER sip:example.com
	To: sip:foo@example.com
	From: sip:baz@example.com
	Supported: gruu
	Expires: 3600
	Contact: sip:xyz@a.example.com;gruu
	Call-Id: 333@a.example.com

Is that legal too? If so, it could result in the same gruu being given 
to bar and baz. Is it also ok to give different ones to each? If 
different ones, does issuing the new one to baz invalidate the one given 
to bar?

In this specific case it probably isn't important what happens. But in 
general it will be hard for the registrar to distinguish bizare cases 
like this from more normal cases where things ought to work. In 
particular, can a registration that doesn't appear to be a refresh 
invalidate a previously issued gruu?

I think the current intent is that the gruu is required to stick with a 
particular contact address as long as that is registered, regardless of 
whether the refresh is technically a refresh from the same source and 
callid or not. If so, then everybody receives the same gruu. That is 
probably ok. If so, continuing the above scenario, suppose the original 
ua now refreshes:

	REGISTER sip:example.com
	To: sip:foo@example.com
	From: sip:foo@example.com
	Expires: 3600
	Contact: sip:xyz@a.example.com
	Call-Id: 111@a.example.com

MUST/SHOULD/MAY the Contact header in the response contain the gruu= 
parameter? My opinion is that it SHOULD.

What about the "reg" event package? If a gruu is associated with a 
particular contact, is that reported in notifications? Does it matter 
whether the subscriber specifes Supported:gruu or not? IMO the gruu MUST 
be included if Supported:gruu is present, and SHOULD be present otherwise.


In section 5:

    ... the GRUU MUST exhibit the
    following properties:

    o  When a request is sent to this URI, it routes to a proxy server in
       the same domain as that of the registrar.

    o  A proxy server in the domain can determine that the URI is a GRUU.

    o  When a proxy server in this domain translates this URI, the result
       is equal to the Contact URI corresponding to the GRUU.

    o  It MUST NOT be possible, based on inspection of the URI, to
       determine the associated Contact URI or Address of Record.

This excludes an interesting special case. It is possible that the 
registrar can determine that the contact address being registered is 
already globally routable. If so, it would be good for the registrar to 
have the option of simply returning the contact address as the gruu. The 
above criteria exclude that possibility.

Of course, that would eliminate the privacy advantage of gruus. But we 
already know that is at best limited. In some cases a UA might prefer 
the performance advantage of bypassing the proxy if it isn't needed. 
What about making the requirement to anonymize the gruu an option on the 
REGISTER?

	Paul


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



From exim@www1.ietf.org  Tue Dec  9 00:47:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28751
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 00:47:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATaiQ-0000ci-8C
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 00:47:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB95lM5I002335
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 00:47:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATai5-0000ag-6O; Tue, 09 Dec 2003 00:47:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATah9-0000a2-03
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 00:46:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28717
	for <sip@ietf.org>; Tue, 9 Dec 2003 00:45:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATah6-0000rS-00
	for sip@ietf.org; Tue, 09 Dec 2003 00:46:00 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATah5-0000r2-00
	for sip@ietf.org; Tue, 09 Dec 2003 00:45:59 -0500
Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB95jXca001890;
	Tue, 9 Dec 2003 00:45:34 -0500 (EST)
Message-ID: <3FD56173.1020104@dynamicsoft.com>
Date: Tue, 09 Dec 2003 00:45:23 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Stredicke <stredicke@snom.de>
CC: "'Chris Boulton'" <cboulton@ubiquity.net>, sip@ietf.org
Subject: Re: AW: [Sip] Updated gruu mechanism spec
References: <008301c3bd6d$969296a0$60fd340a@sip>
In-Reply-To: <008301c3bd6d$969296a0$60fd340a@sip>
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Christian Stredicke wrote:

> Hi Chris,
> 
> well usually it is a good idea for the UAC to close the TCP connection
> in order to keep the load on the server low. But in the specific case of
> obtaining a GRUU (behind NAT) this is not a good practice; therefore I
> think it fits well into the GRUU draft.

Keeping the connection open to the server is a necessary practice for 
SIP to work through nat, independently of whether you are using gruus 
or not. As such, I agree with Chris that this kind of behavior belongs 
in the tcp bcp document that has been discussed on the list.

-Jonathan R.


-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Tue Dec  9 03:33:27 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17231
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 03:33:27 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATdIu-0002C9-79
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 03:33:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB98XC48008431
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 03:33:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATdIk-0002AY-IF; Tue, 09 Dec 2003 03:33:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATdIP-00029T-Gr
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 03:32:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17147
	for <sip@ietf.org>; Tue, 9 Dec 2003 03:32:19 -0500 (EST)
From: aki.niemi@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATdIG-0003QH-00
	for sip@ietf.org; Tue, 09 Dec 2003 03:32:32 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATdIF-0003QE-00
	for sip@ietf.org; Tue, 09 Dec 2003 03:32:31 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB98WUR16677
	for <sip@ietf.org>; Tue, 9 Dec 2003 10:32:30 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6666f44c3cac158f23077@esvir03nok.nokia.com>;
 Tue, 9 Dec 2003 10:32:30 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 9 Dec 2003 10:32:30 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Entity-tags in PUBLISH
Date: Tue, 9 Dec 2003 10:32:29 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9211@esebe013.ntc.nokia.com>
Thread-Topic: [Sip] Entity-tags in PUBLISH
Thread-Index: AcO7cth68Yns47SKRpe6E9MqmXBBxgCu8njg
To: <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 09 Dec 2003 08:32:30.0244 (UTC) FILETIME=[FC049E40:01C3BE2E]
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable


 > -----Original Message-----
 > From: ext Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
 > Sent: 05 December, 2003 23:00
 > To: Niemi Aki (NMP/Helsinki)
 > Cc: sip@ietf.org
 > Subject: Re: [Sip] Entity-tags in PUBLISH
 >=20
 >=20
 > Once the syntax and semantics are not the same, you should=20
 > not use the=20
 > same header name. Even if we added back in the features we=20
 > don't need=20
 > pper se, there is still the issue of SHOULD vs. MUST for etag=20
 > inclusion in the response. I think we definitely want a must. Thus,=20
 > this is a change in behavior from HTTP.
 >=20
 > I would propose we use "SIP-Etag" and "SIP-If-Match" to convey that=20
 > these are similar in scope to their http bretheren, but not the same.

Sounds like a plan.

Cheers,
Aki

 > -Jonathan R.
 >=20
 > aki.niemi@nokia.com wrote:
 >=20
 > > Hi,
 > >=20
 > > As we discussed in Minneapolis, the PUBLISH draft needs=20
 > additional text covering the use of etags, and the=20
 > relationship to HTTP in this respect. One related thing that=20
 > came up was that although the etags in PUBLISH have been=20
 > copied from RFC 2616, there are some minor differences,=20
 > mainly due to the fact that with PUBLISH, we don't have use=20
 > for features used with for example the GET and HEAD methods:
 > >=20
 > >    - We have dropped the weak etag concept, because=20
 > PUBLISH etags are basically=20
 > >      always strong. As a side effect, the syntax is also=20
 > different, i.e., an etag=20
 > >      is a token, instead of quoted-string with an optional=20
 > "weakness" tag prefix.=20
 > >      This seemed reasonable, since this is the common way=20
 > to representing=09
 > >      similar things in SIP, and after removing the weak=20
 > tag, the quotes were=20
 > >      superfluous.
 > >=20
 > >    - We have dropped multiple etags in If-Match header,=20
 > because in PUBLISH, the=20
 > >      EPA will always only modify/remove/refresh its own=20
 > publications. This=20
 > >      corresponds to a conditional PUT in HTTP/1.1, where=20
 > only a single entity-tag=20
 > >      is present in If-Match.
 > >=20
 > >    - We have dropped the "*" valued If-Match. An=20
 > "If-Match: *" corresponds to a=20
 > >      PUBLISH without the If-Match header, so there is no=20
 > need for this special=20
 > >      value.
 > >=20
 > >    - In HTTP/1.1, the origin server SHOULD create an etag,=20
 > whereas in PUBLISH,=20
 > >      the ESC MUST always create an etag.
 > >=20
 > > The main functionality of etags is the same in my opinion,=20
 > even with the above "focused" use of them. But I would still=20
 > like some input on whether the working group feels these=20
 > differences are considerable enough that we should *not*=20
 > inherit the syntax for these headers from HTTP/1.1, but=20
 > create similar but distinct header field names, and response code.
 > >=20
 > > Cheers,
 > > Aki
 > >=20
 > >=20
 > > _______________________________________________
 > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
 > > This list is for NEW development of the core SIP Protocol
 > > Use sip-implementors@cs.columbia.edu for questions on current sip
 > > Use sipping@ietf.org for new developments on the application of sip
 > >=20
 >=20
 > --=20
 > Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
 > Chief Technology Officer                    Parsippany, NJ 07054-2711
 > dynamicsoft
 > jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
 > http://www.jdrosen.net                      PHONE: (973) 952-5000
 > http://www.dynamicsoft.com
 >=20
 >=20

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



From exim@www1.ietf.org  Tue Dec  9 09:21:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26658
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 09:21:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATijo-00070g-Nv
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 09:21:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9ELKpk026942
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 09:21:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATijX-0006zg-JY; Tue, 09 Dec 2003 09:21:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATij5-0006z9-O0
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 09:20:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26647
	for <sip@ietf.org>; Tue, 9 Dec 2003 09:20:19 -0500 (EST)
From: aki.niemi@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATij4-0000C7-00
	for sip@ietf.org; Tue, 09 Dec 2003 09:20:34 -0500
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATij3-0000C4-00
	for sip@ietf.org; Tue, 09 Dec 2003 09:20:33 -0500
Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB9EJW826783
	for <sip@ietf.org>; Tue, 9 Dec 2003 16:20:12 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6668320328ac158f21083@esvir01nok.ntc.nokia.com>;
 Tue, 9 Dec 2003 16:19:32 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 9 Dec 2003 16:19:31 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Dec 2003 16:19:31 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592FC@esebe013.ntc.nokia.com>
Thread-Topic: Contact header in PUBLISH
Thread-Index: AcO8HKJbPSmh1+COShm37a5Dri3SQQCP3B/w
To: <fluffy@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 09 Dec 2003 14:19:31.0879 (UTC) FILETIME=[76ADFB70:01C3BE5F]
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] RE: Contact header in PUBLISH
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi Cullen,

Inline.

 > -----Original Message-----
 > From: ext Cullen Jennings [mailto:fluffy@cisco.com]
 > Sent: 06 December, 2003 19:15
 > To: sip@ietf.org
 > Cc: Niemi Aki (NMP/Helsinki)
 > Subject: Contact header in PUBLISH
 >=20
 >=20
 >=20
 > Right now the draft says "The PUBLISH request MUST NOT=20
 > contain a Contact
 > header."=20
 >=20
 > Why? Does it do any harm? The paragraph before this makes if=20
 > fairly clear
 > that PUBLISH does create a new Dialog.

(I suspect you meant "does *not* create a dialog"?)

Actually, the language in PUBLISH is pretty much equivalent to what =
MESSAGE has -- it too says MUST NOT. The only difference is that PUBLISH =
doesn't talk about sending PUBLISH inside an existing dialog. I actually =
don't see harm in allowing that also for PUBLISH, although it needs to =
explain why quite often that may not result to what you usually want to =
do with PUBLISH.
=20
 > The AIB strongly encourages including the Contact header in=20
 > the sipfrag as
 > correlating material. Clearly we want to use the AIB with=20
 > PUBLISH. Don't
 > know if this really helps the AIB stuff or not.
 >=20
 > Anyways, I understand why the Contact header doesn't mean=20
 > much in a PUBLISH.
 > I don't understand why such strong MUST NOT language.

I tend to agree. Such strong language makes sense for MESSAGE, in that =
we don't want UAs sending response IMs to any Contact addresses, thus =
establishing a dialog of sorts.

PUBLISH is generally never sent in the "other" direction, so I don't see =
any reason not to say:

	PUBLISH request MAY include a Contact header field, although doing so
	has no meaning in the PUBLISH context.

Any other opinions?

Cheers,
Aki

 >=20
 > Cullen
 >=20
 >=20
 >=20

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



From exim@www1.ietf.org  Tue Dec  9 09:36:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26926
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 09:36:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATiyB-0007eH-U4
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 09:36:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9EaBMV029342
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 09:36:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATiy3-0007cO-NJ; Tue, 09 Dec 2003 09:36:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATixK-0007bF-7m
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 09:35:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26890
	for <sip@ietf.org>; Tue, 9 Dec 2003 09:35:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATixI-0000k3-00
	for sip@ietf.org; Tue, 09 Dec 2003 09:35:16 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATixH-0000j5-00
	for sip@ietf.org; Tue, 09 Dec 2003 09:35:15 -0500
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB9EYZxg025065;
	Tue, 9 Dec 2003 09:34:35 -0500 (EST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEN30940;
	Tue, 9 Dec 2003 09:34:33 -0500 (EST)
Message-ID: <3FD5DD79.5050000@cisco.com>
Date: Tue, 09 Dec 2003 09:34:33 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: aki.niemi@nokia.com
CC: fluffy@cisco.com, sip@ietf.org
Subject: Re: [Sip] RE: Contact header in PUBLISH
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592FC@esebe013.ntc.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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



aki.niemi@nokia.com wrote:
> 
> PUBLISH is generally never sent in the "other" direction, so I don't see any reason not to say:
> 
> 	PUBLISH request MAY include a Contact header field, although doing so
> 	has no meaning in the PUBLISH context.
> 
> Any other opinions?

How about another phrasing that says the same thing but emphasizes the 
desired behavior?

        PUBLISH request SHOULD NOT include a Contact header field.
        Including one has no meaning in the PUBLISH context.

Paul


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



From exim@www1.ietf.org  Tue Dec  9 11:10:29 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01729
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 11:10:29 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkRE-0003AH-Kb
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 11:10:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9GAGU9012105
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 11:10:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkR2-00038J-1T; Tue, 09 Dec 2003 11:10:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkQh-000367-Je
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 11:09:43 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01696
	for <sip@ietf.org>; Tue, 9 Dec 2003 11:09:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATkQe-0002Eh-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:09:40 -0500
Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATkQe-0002ER-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:09:40 -0500
Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59)
	id <YH5WXAT7>; Tue, 9 Dec 2003 16:09:00 -0000
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FDB0@baker.datcon.co.uk>
From: "Paul D.Smith" <Paul.D.Smith@dataconnection.com>
To: "'rsparks@dynamicsoft.com'" <rsparks@dynamicsoft.com>
Cc: PDS - SIP <sip@ietf.org>
Date: Tue, 9 Dec 2003 16:09:03 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Referred-By, cid and and URI parameters
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Robert,

I believe there is a minor omission in draft-ietf-sip-referredby.  The BNF
for the Referred-By header allows the following parse "error".

Referred-By: sip:bill@biloxi.com;cid=12345@biloxi.com

The above header might be parsed as a URI containing the URI parameter
"cid=12345@biloxi.com", which is probably not what the referrer intended.

RFC 3261 might have had a similar issue with Contact, From and To headers
but section 20 contains the following clarification.

--- Start quote ---
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.
--- End quote ---

Can a similar paragraph be added to draft-ietf-sip-referredby to clarify
this "feature" of the BNF please?

Paul D.Smith.

Paul D.Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: paul.d.smith@dataconnection.com 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.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 exim@www1.ietf.org  Tue Dec  9 11:13:16 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01867
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 11:13:16 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkTu-0003QY-4i
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 11:13:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9GD2Zg013145
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 11:13:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkTs-0003Ov-Bx; Tue, 09 Dec 2003 11:13:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkT5-0003Ng-6l
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 11:12:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01799
	for <sip@ietf.org>; Tue, 9 Dec 2003 11:11:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATkT3-0002H2-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:12:10 -0500
Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATkT3-0002GF-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:12:09 -0500
Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59)
	id <YH5WXA4P>; Tue, 9 Dec 2003 16:11:30 -0000
Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FDB3@baker.datcon.co.uk>
From: "Paul D.Smith" <Paul.D.Smith@dataconnection.com>
To: PDS - SIP <sip@ietf.org>
Cc: "'rohan@cisco.com'" <rohan@cisco.com>
Date: Tue, 9 Dec 2003 16:11:34 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Connection Reuse and different transports
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Rohan,

I have a question regarding Connection Reuse and the selection of a
transport shown in draft-ietf-sip-connect-reuse-00.txt.

The examples of pages 6 and 7 show the registering of an alias address, in
this case through a Via which indicates TLS.  However the examples then go
on to show what happens only when the preferred transport in the reverse
direction is also TLS (alias is used as expected).  But what happens if the
preferred transport in the reverse direction is _not_ TLS, for example if it
is TCP?  Should the alias now be ignored?

Aside: I am studiously ignoring possible issues about "Contact: should be
SIPS etc".  Consider SCTP and TCP as another example.

I suspect that the alias _should_ be ignored and that the registered alias
is actually transport specific so the check for "should I use an alias"
becomes...

if (target server name/address AND target port name AND target transport ALL
match an alias then)
  use the alias
endif

Assuming that I am correct, could you perhaps add a more explicit example to
the next version of the draft?

Thanks,
Paul DS.

Paul D.Smith
Network Protocols Group 
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: paul.d.smith@dataconnection.com 
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.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 exim@www1.ietf.org  Tue Dec  9 11:42:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02849
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 11:42:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkw3-0005Jj-2T
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 11:42:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9Gg7FJ020411
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 11:42:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkvy-0005I4-4J; Tue, 09 Dec 2003 11:42:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATkvt-0005Ho-Ej
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 11:41:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02831
	for <sip@ietf.org>; Tue, 9 Dec 2003 11:41:40 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATkvs-0002oE-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:41:56 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATkvr-0002nw-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:41:56 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 09 Dec 2003 08:43:23 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB9GfNZ0009712;
	Tue, 9 Dec 2003 08:41:24 -0800 (PST)
Received: from [128.107.171.228] ([128.107.171.228])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AKP01427;
	Tue, 9 Dec 2003 08:41:22 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 09 Dec 2003 08:41:22 -0800
Subject: Re: [Sip] RE: Contact header in PUBLISH
From: Cullen Jennings <fluffy@cisco.com>
To: <aki.niemi@nokia.com>, <sip@ietf.org>
Message-ID: <BBFB3B32.28954%fluffy@cisco.com>
In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592FC@esebe013.ntc.nokia.com>
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On 12/9/03 6:19 AM, "aki.niemi@nokia.com" <aki.niemi@nokia.com> wrote:

> Hi Cullen,
> 
> Inline.
> 
>> -----Original Message-----
>> From: ext Cullen Jennings [mailto:fluffy@cisco.com]

>> Why? Does it do any harm? The paragraph before this makes if
>> fairly clear
>> that PUBLISH does create a new Dialog.
> 
> (I suspect you meant "does *not* create a dialog"?)
>
Oops - what a bad typo. Yes, I meant "does *not* create"


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



From exim@www1.ietf.org  Tue Dec  9 11:50:21 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03287
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 11:50:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATl3o-0005h0-37
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 11:50:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9Go8Pi021857
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 11:50:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATl3j-0005fb-5V; Tue, 09 Dec 2003 11:50:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATl2r-0005eX-Ij
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 11:49:09 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03244
	for <sip@ietf.org>; Tue, 9 Dec 2003 11:48:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATl2q-000301-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:49:08 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATl2p-0002zy-00
	for sip@ietf.org; Tue, 09 Dec 2003 11:49:07 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB9Gn7R04372
	for <sip@ietf.org>; Tue, 9 Dec 2003 18:49:07 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T6668baf386ac158f23077@esvir03nok.nokia.com>;
 Tue, 9 Dec 2003 18:49:06 +0200
Received: from nokia.com ([172.21.11.8]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Tue, 9 Dec 2003 18:49:05 +0200
Message-ID: <3FD5FD01.4000008@nokia.com>
Date: Tue, 09 Dec 2003 18:49:05 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Paul Kyzivat <pkyzivat@cisco.com>
CC: fluffy@cisco.com, sip@ietf.org
Subject: Re: [Sip] RE: Contact header in PUBLISH
References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592FC@esebe013.ntc.nokia.com> <3FD5DD79.5050000@cisco.com>
In-Reply-To: <3FD5DD79.5050000@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Dec 2003 16:49:05.0444 (UTC) FILETIME=[5B575640:01C3BE74]
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



ext Paul Kyzivat wrote:
> aki.niemi@nokia.com wrote:
> 
>>
>> PUBLISH is generally never sent in the "other" direction, so I don't 
>> see any reason not to say:
>>
>>     PUBLISH request MAY include a Contact header field, although doing so
>>     has no meaning in the PUBLISH context.
>>
>> Any other opinions?
> 
> 
> How about another phrasing that says the same thing but emphasizes the 
> desired behavior?
> 
>        PUBLISH request SHOULD NOT include a Contact header field.
>        Including one has no meaning in the PUBLISH context.

I'm OK with that, although my understanding is that if we use SHOULD 
NOT, we should be attaching some description of the circumstances where 
it would be OK to include it.

Cheers,
Aki

> 
> Paul
> 

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



From exim@www1.ietf.org  Tue Dec  9 16:42:25 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18608
	for <sip-archive@odin.ietf.org>; Tue, 9 Dec 2003 16:42:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATpcR-00037Y-8f
	for sip-archive@odin.ietf.org; Tue, 09 Dec 2003 16:42:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9LgBNR011992
	for sip-archive@odin.ietf.org; Tue, 9 Dec 2003 16:42:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATpcG-00036U-VF; Tue, 09 Dec 2003 16:42:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1ATpbj-000360-AH
	for sip@optimus.ietf.org; Tue, 09 Dec 2003 16:41:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18579
	for <sip@ietf.org>; Tue, 9 Dec 2003 16:41:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATpbh-0001Lb-00
	for sip@ietf.org; Tue, 09 Dec 2003 16:41:25 -0500
Received: from natsmtp01.rzone.de ([81.169.145.166])
	by ietf-mx with esmtp (Exim 4.12)
	id 1ATpbg-0001LX-00
	for sip@ietf.org; Tue, 09 Dec 2003 16:41:24 -0500
Received: from sip ([218.106.195.95])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hB9LfBPl015363;
	Tue, 9 Dec 2003 22:41:12 +0100 (MET)
From: "Christian Stredicke" <stredicke@snom.de>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: AW: AW: [Sip] Updated gruu mechanism spec
Date: Wed, 10 Dec 2003 05:41:15 +0800
Message-ID: <021201c3be9d$2dde4470$60fd340a@sip>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <3FD56173.1020104@dynamicsoft.com>
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Jonathan,

if you read carefully you will see that I am talking about the client.
The client usually closes the TCP connection after the transaction or a
short timeout. That is not ok with a REGISTER transaction when gruu and
NAT is involved.

CS

> -----Urspr=FCngliche Nachricht-----
> Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
> Jonathan Rosenberg
> Gesendet: Dienstag, 9. Dezember 2003 13:45
> An: Christian Stredicke
> Cc: 'Chris Boulton'; sip@ietf.org
> Betreff: Re: AW: [Sip] Updated gruu mechanism spec
>=20
>=20
>=20
> Christian Stredicke wrote:
>=20
> > Hi Chris,
> >
> > well usually it is a good idea for the UAC to close the TCP
connection
> > in order to keep the load on the server low. But in the specific
case of
> > obtaining a GRUU (behind NAT) this is not a good practice; therefore
I
> > think it fits well into the GRUU draft.
>=20
> Keeping the connection open to the server is a necessary practice for
> SIP to work through nat, independently of whether you are using gruus
> or not. As such, I agree with Chris that this kind of behavior belongs
> in the tcp bcp document that has been discussed on the list.
>=20
> -Jonathan R.
>=20
>=20
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip


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



From exim@www1.ietf.org  Wed Dec 10 06:32:58 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07987
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 06:32:58 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU2a0-0006HW-RL
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 06:32:32 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBABWWCR024139
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 06:32:32 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU2ZV-0006GN-VR; Wed, 10 Dec 2003 06:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU2ZK-0006Fy-41
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 06:31:50 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07967
	for <sip@ietf.org>; Wed, 10 Dec 2003 06:31:45 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU2ZF-0007f1-00
	for sip@ietf.org; Wed, 10 Dec 2003 06:31:46 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU2ZF-0007ex-00
	for sip@ietf.org; Wed, 10 Dec 2003 06:31:45 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBABVjn13337
	for <sip@ietf.org>; Wed, 10 Dec 2003 13:31:46 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T666cbec523ac158f23077@esvir03nok.nokia.com>;
 Wed, 10 Dec 2003 13:31:45 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Wed, 10 Dec 2003 13:31:45 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Wed, 10 Dec 2003 13:31:45 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Contact header in PUBLISH
Date: Wed, 10 Dec 2003 13:31:45 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974CD@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] RE: Contact header in PUBLISH
Thread-Index: AcO+dJ+JDcYooBniTDqiwbf5NeKLywAnAUUw
To: <aki.niemi@nokia.com>, <pkyzivat@cisco.com>
Cc: <fluffy@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 10 Dec 2003 11:31:45.0542 (UTC) FILETIME=[31169A60:01C3BF11]
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

You never know what us geniuses might come up with in the future as a =
possible use for contact-header in PUBLISH. why eliminate this =
possibility. Including a contact- header in PUBLISH does not break the =
protocol, so no need to explicitly disallow it. I vote for Aki's =
original suggestion of using MAY with a slight modification:

	PUBLISH request MAY include a Contact header field, although doing so
	has no meaning in the PUBLISH context **as defined in this =
specification**.

Regards,
Hisham

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf=20
> Of ext Aki
> Niemi
> Sent: 09.December.2003 18:49
> To: ext Paul Kyzivat
> Cc: fluffy@cisco.com; sip@ietf.org
> Subject: Re: [Sip] RE: Contact header in PUBLISH
>=20
>=20
>=20
>=20
> ext Paul Kyzivat wrote:
> > aki.niemi@nokia.com wrote:
> >=20
> >>
> >> PUBLISH is generally never sent in the "other" direction,=20
> so I don't=20
> >> see any reason not to say:
> >>
> >>     PUBLISH request MAY include a Contact header field,=20
> although doing so
> >>     has no meaning in the PUBLISH context.
> >>
> >> Any other opinions?
> >=20
> >=20
> > How about another phrasing that says the same thing but=20
> emphasizes the=20
> > desired behavior?
> >=20
> >        PUBLISH request SHOULD NOT include a Contact header field.
> >        Including one has no meaning in the PUBLISH context.
>=20
> I'm OK with that, although my understanding is that if we use SHOULD=20
> NOT, we should be attaching some description of the=20
> circumstances where=20
> it would be OK to include it.
>=20
> Cheers,
> Aki
>=20
> >=20
> > Paul
> >=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

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



From exim@www1.ietf.org  Wed Dec 10 06:41:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08169
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 06:41:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU2iM-0006u4-00
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 06:41:10 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBABf9Gk026533
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 06:41:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU2iE-0006t2-Hr; Wed, 10 Dec 2003 06:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU2hQ-0006s4-Pf
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 06:40:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08142
	for <sip@ietf.org>; Wed, 10 Dec 2003 06:40:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU2hM-0007m5-00
	for sip@ietf.org; Wed, 10 Dec 2003 06:40:08 -0500
Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU2hM-0007lt-00
	for sip@ietf.org; Wed, 10 Dec 2003 06:40:08 -0500
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBABd9003969
	for <sip@ietf.org>; Wed, 10 Dec 2003 05:39:10 -0600 (CST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59)
	id <4M3XWBVY>; Wed, 10 Dec 2003 11:39:08 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF5E@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'hisham.khartabil@nokia.com'" <hisham.khartabil@nokia.com>,
        aki.niemi@nokia.com, pkyzivat@cisco.com
Cc: fluffy@cisco.com, sip@ietf.org
Subject: RE: [Sip] RE: Contact header in PUBLISH
Date: Wed, 10 Dec 2003 11:39:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

If we identify another usage for this header in the future, then presumably we need to write another RFC to do it superceding the current PUBLISH RFC either fully or in part.

The question we therefore need to ask is whether either text has compatibility problems with such a future extension, and I believe the answer is no.

I therefore prefer Paul's text, as it leaves fewer unanswered questions as to whether I put it in now or not. As regards Hisham's current text, I am left with the question of whether I should put it in just in case.

regards

Keith



> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: 10 December 2003 11:32
> To: aki.niemi@nokia.com; pkyzivat@cisco.com
> Cc: fluffy@cisco.com; sip@ietf.org
> Subject: RE: [Sip] RE: Contact header in PUBLISH
> 
> 
> You never know what us geniuses might come up with in the 
> future as a possible use for contact-header in PUBLISH. why 
> eliminate this possibility. Including a contact- header in 
> PUBLISH does not break the protocol, so no need to explicitly 
> disallow it. I vote for Aki's original suggestion of using 
> MAY with a slight modification:
> 
> 	PUBLISH request MAY include a Contact header field, 
> although doing so
> 	has no meaning in the PUBLISH context **as defined in 
> this specification**.
> 
> Regards,
> Hisham
> 
> > -----Original Message-----
> > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf 
> > Of ext Aki
> > Niemi
> > Sent: 09.December.2003 18:49
> > To: ext Paul Kyzivat
> > Cc: fluffy@cisco.com; sip@ietf.org
> > Subject: Re: [Sip] RE: Contact header in PUBLISH
> > 
> > 
> > 
> > 
> > ext Paul Kyzivat wrote:
> > > aki.niemi@nokia.com wrote:
> > > 
> > >>
> > >> PUBLISH is generally never sent in the "other" direction, 
> > so I don't 
> > >> see any reason not to say:
> > >>
> > >>     PUBLISH request MAY include a Contact header field, 
> > although doing so
> > >>     has no meaning in the PUBLISH context.
> > >>
> > >> Any other opinions?
> > > 
> > > 
> > > How about another phrasing that says the same thing but 
> > emphasizes the 
> > > desired behavior?
> > > 
> > >        PUBLISH request SHOULD NOT include a Contact header field.
> > >        Including one has no meaning in the PUBLISH context.
> > 
> > I'm OK with that, although my understanding is that if we 
> use SHOULD 
> > NOT, we should be attaching some description of the 
> > circumstances where 
> > it would be OK to include it.
> > 
> > Cheers,
> > Aki
> > 
> > > 
> > > Paul
> > > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> > 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 

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



From exim@www1.ietf.org  Wed Dec 10 09:32:48 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13172
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 09:32:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5O0-0004Ec-UY
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:32:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAEWKgL016272
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:32:20 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5Nh-0004DW-QQ; Wed, 10 Dec 2003 09:32:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5NC-0004Cu-1j
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 09:31:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13060
	for <sip@ietf.org>; Wed, 10 Dec 2003 09:31:26 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5NA-0002wG-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:31:28 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5N9-0002wA-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:31:27 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBAEVQn01801
	for <sip@ietf.org>; Wed, 10 Dec 2003 16:31:26 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T666d63438aac158f23077@esvir03nok.nokia.com>;
 Wed, 10 Dec 2003 16:31:26 +0200
Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Wed, 10 Dec 2003 16:31:26 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Wed, 10 Dec 2003 16:31:25 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Contact header in PUBLISH
Date: Wed, 10 Dec 2003 16:31:25 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B135@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] RE: Contact header in PUBLISH
Thread-Index: AcO/Ej4GMZ1eq68DShqrwejisVej3wAF07AA
To: <drage@lucent.com>, <aki.niemi@nokia.com>, <pkyzivat@cisco.com>
Cc: <fluffy@cisco.com>, <sip@ietf.org>
X-OriginalArrivalTime: 10 Dec 2003 14:31:25.0897 (UTC) FILETIME=[4AAE3B90:01C3BF2A]
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable



> -----Original Message-----
> From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]
> Sent: 10.December.2003 13:39
> To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
> pkyzivat@cisco.com
> Cc: fluffy@cisco.com; sip@ietf.org
> Subject: RE: [Sip] RE: Contact header in PUBLISH
>=20
>=20
> If we identify another usage for this header in the future,=20
> then presumably we need to write another RFC to do it=20
> superceding the current PUBLISH RFC either fully or in part.
>=20
> The question we therefore need to ask is whether either text=20
> has compatibility problems with such a future extension, and=20
> I believe the answer is no.

If one RFC disallows something and an extension to it allows the exact =
same thing that is disallowed, then we have a problem. If something is =
disallowed, it should stay that way, even in extensions.

>=20
> I therefore prefer Paul's text, as it leaves fewer unanswered=20
> questions as to whether I put it in now or not. As regards=20
> Hisham's current text, I am left with the question of whether=20
> I should put it in just in case.

My text (well, Aki's) is clear, you may put contact-header, but it =
doesn't buy you anything. Common sense will tell someone not to include =
it. Even if you include it, so what?

Regards,
Hisham

>=20
> regards
>=20
> Keith
>=20
>=20
>=20
> > -----Original Message-----
> > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> > Sent: 10 December 2003 11:32
> > To: aki.niemi@nokia.com; pkyzivat@cisco.com
> > Cc: fluffy@cisco.com; sip@ietf.org
> > Subject: RE: [Sip] RE: Contact header in PUBLISH
> >=20
> >=20
> > You never know what us geniuses might come up with in the=20
> > future as a possible use for contact-header in PUBLISH. why=20
> > eliminate this possibility. Including a contact- header in=20
> > PUBLISH does not break the protocol, so no need to explicitly=20
> > disallow it. I vote for Aki's original suggestion of using=20
> > MAY with a slight modification:
> >=20
> > 	PUBLISH request MAY include a Contact header field,=20
> > although doing so
> > 	has no meaning in the PUBLISH context **as defined in=20
> > this specification**.
> >=20
> > Regards,
> > Hisham
> >=20
> > > -----Original Message-----
> > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf=20
> > > Of ext Aki
> > > Niemi
> > > Sent: 09.December.2003 18:49
> > > To: ext Paul Kyzivat
> > > Cc: fluffy@cisco.com; sip@ietf.org
> > > Subject: Re: [Sip] RE: Contact header in PUBLISH
> > >=20
> > >=20
> > >=20
> > >=20
> > > ext Paul Kyzivat wrote:
> > > > aki.niemi@nokia.com wrote:
> > > >=20
> > > >>
> > > >> PUBLISH is generally never sent in the "other" direction,=20
> > > so I don't=20
> > > >> see any reason not to say:
> > > >>
> > > >>     PUBLISH request MAY include a Contact header field,=20
> > > although doing so
> > > >>     has no meaning in the PUBLISH context.
> > > >>
> > > >> Any other opinions?
> > > >=20
> > > >=20
> > > > How about another phrasing that says the same thing but=20
> > > emphasizes the=20
> > > > desired behavior?
> > > >=20
> > > >        PUBLISH request SHOULD NOT include a Contact=20
> header field.
> > > >        Including one has no meaning in the PUBLISH context.
> > >=20
> > > I'm OK with that, although my understanding is that if we=20
> > use SHOULD=20
> > > NOT, we should be attaching some description of the=20
> > > circumstances where=20
> > > it would be OK to include it.
> > >=20
> > > Cheers,
> > > Aki
> > >=20
> > > >=20
> > > > Paul
> > > >=20
> > >=20
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the=20
> application of sip
> > >=20
> >=20
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> >=20
>=20

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



From exim@www1.ietf.org  Wed Dec 10 09:43:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13643
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 09:43:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5YS-0004xr-7M
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:43:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAEh8ap019082
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:43:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5YM-0004wc-8Z; Wed, 10 Dec 2003 09:43:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5YG-0004wC-Ac
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 09:42:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13630
	for <sip@ietf.org>; Wed, 10 Dec 2003 09:42:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5YE-0003Bz-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:42:54 -0500
Received: from mtagate4.de.ibm.com ([195.212.29.153])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5YC-0003Bj-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:42:52 -0500
Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180] (may be forged))
	by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id hBAEfcPg105762;
	Wed, 10 Dec 2003 14:41:38 GMT
Received: from d10ml001.telaviv.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])
	by d12relay01.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id hBAEfbAd266728;
	Wed, 10 Dec 2003 15:41:38 +0100
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B135@esebe019.ntc.nokia.com>
MIME-Version: 1.0
To: hisham.khartabil@nokia.com
Cc: aki.niemi@nokia.com, drage@lucent.com, fluffy@cisco.com,
        pkyzivat@cisco.com, sip@ietf.org
Subject: RE: [Sip] RE: Contact header in PUBLISH
X-Mailer: Lotus Notes Build V65_07292003 July 29, 2003
Message-ID: <OFEFD7C2F3.09069CB4-ONC2256DF8.00507A73-C2256DF8.0050B2E8@il.ibm.com>
From: Avshalom Houri <AVSHALOM@il.ibm.com>
Date: Wed, 10 Dec 2003 16:41:32 +0200
X-MIMETrack: Serialize by Router on D10ML001/10/M/IBM(Release 6.0.2CF2|July 23, 2003) at
 10/12/2003 16:41:38,
	Serialize complete at 10/12/2003 16:41:38
Content-Type: multipart/alternative; boundary="=_alternative 0050B2E3C2256DF8_="
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

This is a multipart message in MIME format.
--=_alternative 0050B2E3C2256DF8_=
Content-Type: text/plain; charset="US-ASCII"

I also think that Aki's text is clearer. People tend to understand "SHOULD 
NOT" as
"MUST NOT". It may cause implementations to reject a PUBLISH that has a
contact header.

Avshalom




hisham.khartabil@nokia.com 
Sent by: sip-admin@ietf.org
10/12/2003 04:31 PM

To
<drage@lucent.com>, <aki.niemi@nokia.com>, <pkyzivat@cisco.com>
cc
<fluffy@cisco.com>, <sip@ietf.org>
Subject
RE: [Sip] RE: Contact header in PUBLISH








> -----Original Message-----
> From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]
> Sent: 10.December.2003 13:39
> To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
> pkyzivat@cisco.com
> Cc: fluffy@cisco.com; sip@ietf.org
> Subject: RE: [Sip] RE: Contact header in PUBLISH
> 
> 
> If we identify another usage for this header in the future, 
> then presumably we need to write another RFC to do it 
> superceding the current PUBLISH RFC either fully or in part.
> 
> The question we therefore need to ask is whether either text 
> has compatibility problems with such a future extension, and 
> I believe the answer is no.

If one RFC disallows something and an extension to it allows the exact 
same thing that is disallowed, then we have a problem. If something is 
disallowed, it should stay that way, even in extensions.

> 
> I therefore prefer Paul's text, as it leaves fewer unanswered 
> questions as to whether I put it in now or not. As regards 
> Hisham's current text, I am left with the question of whether 
> I should put it in just in case.

My text (well, Aki's) is clear, you may put contact-header, but it doesn't 
buy you anything. Common sense will tell someone not to include it. Even 
if you include it, so what?

Regards,
Hisham

> 
> regards
> 
> Keith
> 
> 
> 
> > -----Original Message-----
> > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> > Sent: 10 December 2003 11:32
> > To: aki.niemi@nokia.com; pkyzivat@cisco.com
> > Cc: fluffy@cisco.com; sip@ietf.org
> > Subject: RE: [Sip] RE: Contact header in PUBLISH
> > 
> > 
> > You never know what us geniuses might come up with in the 
> > future as a possible use for contact-header in PUBLISH. why 
> > eliminate this possibility. Including a contact- header in 
> > PUBLISH does not break the protocol, so no need to explicitly 
> > disallow it. I vote for Aki's original suggestion of using 
> > MAY with a slight modification:
> > 
> >              PUBLISH request MAY include a Contact header field, 
> > although doing so
> >              has no meaning in the PUBLISH context **as defined in 
> > this specification**.
> > 
> > Regards,
> > Hisham
> > 
> > > -----Original Message-----
> > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf 
> > > Of ext Aki
> > > Niemi
> > > Sent: 09.December.2003 18:49
> > > To: ext Paul Kyzivat
> > > Cc: fluffy@cisco.com; sip@ietf.org
> > > Subject: Re: [Sip] RE: Contact header in PUBLISH
> > > 
> > > 
> > > 
> > > 
> > > ext Paul Kyzivat wrote:
> > > > aki.niemi@nokia.com wrote:
> > > > 
> > > >>
> > > >> PUBLISH is generally never sent in the "other" direction, 
> > > so I don't 
> > > >> see any reason not to say:
> > > >>
> > > >>     PUBLISH request MAY include a Contact header field, 
> > > although doing so
> > > >>     has no meaning in the PUBLISH context.
> > > >>
> > > >> Any other opinions?
> > > > 
> > > > 
> > > > How about another phrasing that says the same thing but 
> > > emphasizes the 
> > > > desired behavior?
> > > > 
> > > >        PUBLISH request SHOULD NOT include a Contact 
> header field.
> > > >        Including one has no meaning in the PUBLISH context.
> > > 
> > > I'm OK with that, although my understanding is that if we 
> > use SHOULD 
> > > NOT, we should be attaching some description of the 
> > > circumstances where 
> > > it would be OK to include it.
> > > 
> > > Cheers,
> > > Aki
> > > 
> > > > 
> > > > Paul
> > > > 
> > > 
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the 
> application of sip
> > > 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org for new developments on the application of sip
> > 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP 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 0050B2E3C2256DF8_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">I also think that Aki's text is clearer.
People tend to understand &quot;SHOULD NOT&quot; as</font>
<br><font size=2 face="sans-serif">&quot;MUST NOT&quot;. It may cause implementations
to reject a PUBLISH that has a</font>
<br><font size=2 face="sans-serif">contact header.</font>
<br>
<br><font size=2 face="sans-serif">Avshalom</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>hisham.khartabil@nokia.com</b>
</font>
<br><font size=1 face="sans-serif">Sent by: sip-admin@ietf.org</font>
<p><font size=1 face="sans-serif">10/12/2003 04:31 PM</font>
<td width=59%>
<table width=100%>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td valign=top><font size=1 face="sans-serif">&lt;drage@lucent.com&gt;,
&lt;aki.niemi@nokia.com&gt;, &lt;pkyzivat@cisco.com&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td valign=top><font size=1 face="sans-serif">&lt;fluffy@cisco.com&gt;,
&lt;sip@ietf.org&gt;</font>
<tr>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td valign=top><font size=1 face="sans-serif">RE: [Sip] RE: Contact header
in PUBLISH</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
<br>
&gt; -----Original Message-----<br>
&gt; From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]<br>
&gt; Sent: 10.December.2003 13:39<br>
&gt; To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);<br>
&gt; pkyzivat@cisco.com<br>
&gt; Cc: fluffy@cisco.com; sip@ietf.org<br>
&gt; Subject: RE: [Sip] RE: Contact header in PUBLISH<br>
&gt; <br>
&gt; <br>
&gt; If we identify another usage for this header in the future, <br>
&gt; then presumably we need to write another RFC to do it <br>
&gt; superceding the current PUBLISH RFC either fully or in part.<br>
&gt; <br>
&gt; The question we therefore need to ask is whether either text <br>
&gt; has compatibility problems with such a future extension, and <br>
&gt; I believe the answer is no.<br>
<br>
If one RFC disallows something and an extension to it allows the exact
same thing that is disallowed, then we have a problem. If something is
disallowed, it should stay that way, even in extensions.<br>
<br>
&gt; <br>
&gt; I therefore prefer Paul's text, as it leaves fewer unanswered <br>
&gt; questions as to whether I put it in now or not. As regards <br>
&gt; Hisham's current text, I am left with the question of whether <br>
&gt; I should put it in just in case.<br>
<br>
My text (well, Aki's) is clear, you may put contact-header, but it doesn't
buy you anything. Common sense will tell someone not to include it. Even
if you include it, so what?<br>
<br>
Regards,<br>
Hisham<br>
<br>
&gt; <br>
&gt; regards<br>
&gt; <br>
&gt; Keith<br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]<br>
&gt; &gt; Sent: 10 December 2003 11:32<br>
&gt; &gt; To: aki.niemi@nokia.com; pkyzivat@cisco.com<br>
&gt; &gt; Cc: fluffy@cisco.com; sip@ietf.org<br>
&gt; &gt; Subject: RE: [Sip] RE: Contact header in PUBLISH<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; You never know what us geniuses might come up with in the <br>
&gt; &gt; future as a possible use for contact-header in PUBLISH. why <br>
&gt; &gt; eliminate this possibility. Including a contact- header in <br>
&gt; &gt; PUBLISH does not break the protocol, so no need to explicitly
<br>
&gt; &gt; disallow it. I vote for Aki's original suggestion of using <br>
&gt; &gt; MAY with a slight modification:<br>
&gt; &gt; <br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;PUBLISH request MAY include a Contact header field, <br>
&gt; &gt; although doing so<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp;has no meaning in the PUBLISH context **as defined in <br>
&gt; &gt; this specification**.<br>
&gt; &gt; <br>
&gt; &gt; Regards,<br>
&gt; &gt; Hisham<br>
&gt; &gt; <br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
<br>
&gt; &gt; &gt; Of ext Aki<br>
&gt; &gt; &gt; Niemi<br>
&gt; &gt; &gt; Sent: 09.December.2003 18:49<br>
&gt; &gt; &gt; To: ext Paul Kyzivat<br>
&gt; &gt; &gt; Cc: fluffy@cisco.com; sip@ietf.org<br>
&gt; &gt; &gt; Subject: Re: [Sip] RE: Contact header in PUBLISH<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; ext Paul Kyzivat wrote:<br>
&gt; &gt; &gt; &gt; aki.niemi@nokia.com wrote:<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; PUBLISH is generally never sent in the &quot;other&quot;
direction, <br>
&gt; &gt; &gt; so I don't <br>
&gt; &gt; &gt; &gt;&gt; see any reason not to say:<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; &nbsp; &nbsp; PUBLISH request MAY include a Contact
header field, <br>
&gt; &gt; &gt; although doing so<br>
&gt; &gt; &gt; &gt;&gt; &nbsp; &nbsp; has no meaning in the PUBLISH context.<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; Any other opinions?<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; How about another phrasing that says the same thing
but <br>
&gt; &gt; &gt; emphasizes the <br>
&gt; &gt; &gt; &gt; desired behavior?<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;PUBLISH request SHOULD NOT
include a Contact <br>
&gt; header field.<br>
&gt; &gt; &gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp;Including one has no meaning
in the PUBLISH context.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; I'm OK with that, although my understanding is that if we
<br>
&gt; &gt; use SHOULD <br>
&gt; &gt; &gt; NOT, we should be attaching some description of the <br>
&gt; &gt; &gt; circumstances where <br>
&gt; &gt; &gt; it would be OK to include it.<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; Cheers,<br>
&gt; &gt; &gt; Aki<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; Paul<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; Sip mailing list &nbsp;https://www1.ietf.org/mailman/listinfo/sip<br>
&gt; &gt; &gt; This list is for NEW development of the core SIP Protocol<br>
&gt; &gt; &gt; Use sip-implementors@cs.columbia.edu for questions on current
sip<br>
&gt; &gt; &gt; Use sipping@ietf.org for new developments on the <br>
&gt; application of sip<br>
&gt; &gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Sip mailing list &nbsp;https://www1.ietf.org/mailman/listinfo/sip<br>
&gt; &gt; This list is for NEW development of the core SIP Protocol<br>
&gt; &gt; Use sip-implementors@cs.columbia.edu for questions on current
sip<br>
&gt; &gt; Use sipping@ietf.org for new developments on the application
of sip<br>
&gt; &gt; <br>
&gt; <br>
<br>
_______________________________________________<br>
Sip mailing list &nbsp;https://www1.ietf.org/mailman/listinfo/sip<br>
This list is for NEW development of the core SIP Protocol<br>
Use sip-implementors@cs.columbia.edu for questions on current sip<br>
Use sipping@ietf.org for new developments on the application of sip<br>
</tt></font>
<br>
--=_alternative 0050B2E3C2256DF8_=--

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



From exim@www1.ietf.org  Wed Dec 10 09:51:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13827
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 09:51:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5gB-0005RY-S0
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:51:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAEp7iW020898
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:51:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5g7-0005QC-DY; Wed, 10 Dec 2003 09:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5fY-0005PJ-CN
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 09:50:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13782
	for <sip@ietf.org>; Wed, 10 Dec 2003 09:50:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5fW-0003Hv-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:50:26 -0500
Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5fW-0003Hb-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:50:26 -0500
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBAEnpc27336
	for <sip@ietf.org>; Wed, 10 Dec 2003 08:49:52 -0600 (CST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2656.59)
	id <4M3XW2Q0>; Wed, 10 Dec 2003 14:49:50 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF61@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'hisham.khartabil@nokia.com'" <hisham.khartabil@nokia.com>,
        "Drage, Keith (Keith)" <drage@lucent.com>, aki.niemi@nokia.com,
        pkyzivat@cisco.com
Cc: fluffy@cisco.com, sip@ietf.org
Subject: RE: [Sip] RE: Contact header in PUBLISH
Date: Wed, 10 Dec 2003 14:49:46 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

But Paul's text does not disallow, it says SHOULD NOT, not MUST NOT, so all recipients must cater for its inclusion, even if they have no use for it.

regards

Keith

> -----Original Message-----
> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
> Sent: 10 December 2003 14:31
> To: drage@lucent.com; aki.niemi@nokia.com; pkyzivat@cisco.com
> Cc: fluffy@cisco.com; sip@ietf.org
> Subject: RE: [Sip] RE: Contact header in PUBLISH
> 
> 
> 
> 
> > -----Original Message-----
> > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]
> > Sent: 10.December.2003 13:39
> > To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
> > pkyzivat@cisco.com
> > Cc: fluffy@cisco.com; sip@ietf.org
> > Subject: RE: [Sip] RE: Contact header in PUBLISH
> > 
> > 
> > If we identify another usage for this header in the future, 
> > then presumably we need to write another RFC to do it 
> > superceding the current PUBLISH RFC either fully or in part.
> > 
> > The question we therefore need to ask is whether either text 
> > has compatibility problems with such a future extension, and 
> > I believe the answer is no.
> 
> If one RFC disallows something and an extension to it allows 
> the exact same thing that is disallowed, then we have a 
> problem. If something is disallowed, it should stay that way, 
> even in extensions.
> 
> > 
> > I therefore prefer Paul's text, as it leaves fewer unanswered 
> > questions as to whether I put it in now or not. As regards 
> > Hisham's current text, I am left with the question of whether 
> > I should put it in just in case.
> 
> My text (well, Aki's) is clear, you may put contact-header, 
> but it doesn't buy you anything. Common sense will tell 
> someone not to include it. Even if you include it, so what?
> 
> Regards,
> Hisham
> 
> > 
> > regards
> > 
> > Keith
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: hisham.khartabil@nokia.com 
> [mailto:hisham.khartabil@nokia.com]
> > > Sent: 10 December 2003 11:32
> > > To: aki.niemi@nokia.com; pkyzivat@cisco.com
> > > Cc: fluffy@cisco.com; sip@ietf.org
> > > Subject: RE: [Sip] RE: Contact header in PUBLISH
> > > 
> > > 
> > > You never know what us geniuses might come up with in the 
> > > future as a possible use for contact-header in PUBLISH. why 
> > > eliminate this possibility. Including a contact- header in 
> > > PUBLISH does not break the protocol, so no need to explicitly 
> > > disallow it. I vote for Aki's original suggestion of using 
> > > MAY with a slight modification:
> > > 
> > > 	PUBLISH request MAY include a Contact header field, 
> > > although doing so
> > > 	has no meaning in the PUBLISH context **as defined in 
> > > this specification**.
> > > 
> > > Regards,
> > > Hisham
> > > 
> > > > -----Original Message-----
> > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf 
> > > > Of ext Aki
> > > > Niemi
> > > > Sent: 09.December.2003 18:49
> > > > To: ext Paul Kyzivat
> > > > Cc: fluffy@cisco.com; sip@ietf.org
> > > > Subject: Re: [Sip] RE: Contact header in PUBLISH
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ext Paul Kyzivat wrote:
> > > > > aki.niemi@nokia.com wrote:
> > > > > 
> > > > >>
> > > > >> PUBLISH is generally never sent in the "other" direction, 
> > > > so I don't 
> > > > >> see any reason not to say:
> > > > >>
> > > > >>     PUBLISH request MAY include a Contact header field, 
> > > > although doing so
> > > > >>     has no meaning in the PUBLISH context.
> > > > >>
> > > > >> Any other opinions?
> > > > > 
> > > > > 
> > > > > How about another phrasing that says the same thing but 
> > > > emphasizes the 
> > > > > desired behavior?
> > > > > 
> > > > >        PUBLISH request SHOULD NOT include a Contact 
> > header field.
> > > > >        Including one has no meaning in the PUBLISH context.
> > > > 
> > > > I'm OK with that, although my understanding is that if we 
> > > use SHOULD 
> > > > NOT, we should be attaching some description of the 
> > > > circumstances where 
> > > > it would be OK to include it.
> > > > 
> > > > Cheers,
> > > > Aki
> > > > 
> > > > > 
> > > > > Paul
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol
> > > > Use sip-implementors@cs.columbia.edu for questions on 
> current sip
> > > > Use sipping@ietf.org for new developments on the 
> > application of sip
> > > > 
> > > 
> > > _______________________________________________
> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > This list is for NEW development of the core SIP Protocol
> > > Use sip-implementors@cs.columbia.edu for questions on current sip
> > > Use sipping@ietf.org for new developments on the 
> application of sip
> > > 
> > 
> 

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



From exim@www1.ietf.org  Wed Dec 10 09:59:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14177
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 09:59:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5nv-0005zs-Hp
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:59:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAEx7eY023046
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 09:59:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5np-0005yr-Mr; Wed, 10 Dec 2003 09:59:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AU5nd-0005yV-2k
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 09:58:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14162
	for <sip@ietf.org>; Wed, 10 Dec 2003 09:58:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5nb-0003QP-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:58:47 -0500
Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly07a.srv.mailcontrol.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AU5na-0003Q6-00
	for sip@ietf.org; Wed, 10 Dec 2003 09:58:46 -0500
Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by rly07a.srv.mailcontrol.com (MailControl) with SMTP id hBAEvuiP002188;
	Wed, 10 Dec 2003 14:57:57 GMT
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Wed, 10 Dec 2003 15:00:30 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] RE: Contact header in PUBLISH
Date: Wed, 10 Dec 2003 14:57:56 -0000
Message-ID: <45730E094814E44488F789C1CDED27AE01E22F38@gbnewp0758m.eu.ubiquity.net>
Thread-Topic: [Sip] RE: Contact header in PUBLISH
Thread-Index: AcO/LRALp0XD7u2GRoio1Buywhd7yQAAKBXQ
From: "Chris Boulton" <cboulton@ubiquity.net>
To: "Drage, Keith (Keith)" <drage@lucent.com>, <hisham.khartabil@nokia.com>,
        <aki.niemi@nokia.com>, <pkyzivat@cisco.com>
Cc: <fluffy@cisco.com>, <sip@ietf.org>
X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com)
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

I think the 'MAY' option does provide more scope for future extensions.
You might see a contact, but ignore it.  I understand what Keith is
saying BUT there is the danger of implementations rejecting on SHOULD
NOT, even though this is wrong.=20

>-----Original Message-----
>From: Drage, Keith (Keith) [mailto:drage@lucent.com]
>Sent: 10 December 2003 14:50
>To: 'hisham.khartabil@nokia.com'; Drage, Keith (Keith);
>aki.niemi@nokia.com; pkyzivat@cisco.com
>Cc: fluffy@cisco.com; sip@ietf.org
>Subject: RE: [Sip] RE: Contact header in PUBLISH
>
>But Paul's text does not disallow, it says SHOULD NOT, not MUST NOT, so
all
>recipients must cater for its inclusion, even if they have no use for
it.
>
>regards
>
>Keith
>
>> -----Original Message-----
>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>> Sent: 10 December 2003 14:31
>> To: drage@lucent.com; aki.niemi@nokia.com; pkyzivat@cisco.com
>> Cc: fluffy@cisco.com; sip@ietf.org
>> Subject: RE: [Sip] RE: Contact header in PUBLISH
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]
>> > Sent: 10.December.2003 13:39
>> > To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
>> > pkyzivat@cisco.com
>> > Cc: fluffy@cisco.com; sip@ietf.org
>> > Subject: RE: [Sip] RE: Contact header in PUBLISH
>> >
>> >
>> > If we identify another usage for this header in the future,
>> > then presumably we need to write another RFC to do it
>> > superceding the current PUBLISH RFC either fully or in part.
>> >
>> > The question we therefore need to ask is whether either text
>> > has compatibility problems with such a future extension, and
>> > I believe the answer is no.
>>
>> If one RFC disallows something and an extension to it allows
>> the exact same thing that is disallowed, then we have a
>> problem. If something is disallowed, it should stay that way,
>> even in extensions.
>>
>> >
>> > I therefore prefer Paul's text, as it leaves fewer unanswered
>> > questions as to whether I put it in now or not. As regards
>> > Hisham's current text, I am left with the question of whether
>> > I should put it in just in case.
>>
>> My text (well, Aki's) is clear, you may put contact-header,
>> but it doesn't buy you anything. Common sense will tell
>> someone not to include it. Even if you include it, so what?
>>
>> Regards,
>> Hisham
>>
>> >
>> > regards
>> >
>> > Keith
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: hisham.khartabil@nokia.com
>> [mailto:hisham.khartabil@nokia.com]
>> > > Sent: 10 December 2003 11:32
>> > > To: aki.niemi@nokia.com; pkyzivat@cisco.com
>> > > Cc: fluffy@cisco.com; sip@ietf.org
>> > > Subject: RE: [Sip] RE: Contact header in PUBLISH
>> > >
>> > >
>> > > You never know what us geniuses might come up with in the
>> > > future as a possible use for contact-header in PUBLISH. why
>> > > eliminate this possibility. Including a contact- header in
>> > > PUBLISH does not break the protocol, so no need to explicitly
>> > > disallow it. I vote for Aki's original suggestion of using
>> > > MAY with a slight modification:
>> > >
>> > > 	PUBLISH request MAY include a Contact header field,
>> > > although doing so
>> > > 	has no meaning in the PUBLISH context **as defined in
>> > > this specification**.
>> > >
>> > > Regards,
>> > > Hisham
>> > >
>> > > > -----Original Message-----
>> > > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
>> > > > Of ext Aki
>> > > > Niemi
>> > > > Sent: 09.December.2003 18:49
>> > > > To: ext Paul Kyzivat
>> > > > Cc: fluffy@cisco.com; sip@ietf.org
>> > > > Subject: Re: [Sip] RE: Contact header in PUBLISH
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > ext Paul Kyzivat wrote:
>> > > > > aki.niemi@nokia.com wrote:
>> > > > >
>> > > > >>
>> > > > >> PUBLISH is generally never sent in the "other" direction,
>> > > > so I don't
>> > > > >> see any reason not to say:
>> > > > >>
>> > > > >>     PUBLISH request MAY include a Contact header field,
>> > > > although doing so
>> > > > >>     has no meaning in the PUBLISH context.
>> > > > >>
>> > > > >> Any other opinions?
>> > > > >
>> > > > >
>> > > > > How about another phrasing that says the same thing but
>> > > > emphasizes the
>> > > > > desired behavior?
>> > > > >
>> > > > >        PUBLISH request SHOULD NOT include a Contact
>> > header field.
>> > > > >        Including one has no meaning in the PUBLISH context.
>> > > >
>> > > > I'm OK with that, although my understanding is that if we
>> > > use SHOULD
>> > > > NOT, we should be attaching some description of the
>> > > > circumstances where
>> > > > it would be OK to include it.
>> > > >
>> > > > Cheers,
>> > > > Aki
>> > > >
>> > > > >
>> > > > > Paul
>> > > > >
>> > > >
>> > > > _______________________________________________
>> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> > > > This list is for NEW development of the core SIP Protocol
>> > > > Use sip-implementors@cs.columbia.edu for questions on
>> current sip
>> > > > Use sipping@ietf.org for new developments on the
>> > application of sip
>> > > >
>> > >
>> > > _______________________________________________
>> > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> > > This list is for NEW development of the core SIP Protocol
>> > > Use sip-implementors@cs.columbia.edu for questions on current sip
>> > > Use sipping@ietf.org for new developments on the
>> application of sip
>> > >
>> >
>>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


This message has been scanned for viruses by MailControl - www.mailcontrol.=
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 exim@www1.ietf.org  Wed Dec 10 15:15:46 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14013
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 15:15:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUAjr-0004Rr-6X
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 15:15:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAKFFRA017042
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 15:15:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUAjf-0004Q1-Jj; Wed, 10 Dec 2003 15:15:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUAjO-0004P7-Pb
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 15:14:46 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13900
	for <sip@ietf.org>; Wed, 10 Dec 2003 15:14:44 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUAjM-0000T1-00
	for sip@ietf.org; Wed, 10 Dec 2003 15:14:44 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUAjL-0000Sy-00
	for sip@ietf.org; Wed, 10 Dec 2003 15:14:44 -0500
Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hBAKHeY4013465
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Wed, 10 Dec 2003 14:17:40 -0600
From: "Dean Willis" <dean.willis@softarmor.com>
To: "'Drage, Keith \(Keith\)'" <drage@lucent.com>,
        <hisham.khartabil@nokia.com>, <aki.niemi@nokia.com>,
        <pkyzivat@cisco.com>
Cc: <fluffy@cisco.com>, <sip@ietf.org>
Subject: RE: [Sip] RE: Contact header in PUBLISH
Date: Wed, 10 Dec 2003 14:14:10 -0600
Message-ID: <002501c3bf5a$2cc362b0$e1036e3f@txdwillis>
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.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF61@en0033exch001u.uk.lucent.com>
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


> But Paul's text does not disallow, it says SHOULD NOT, not 
> MUST NOT, so all recipients must cater for its inclusion, 
> even if they have no use for it.

"Be liberal in what you accept, and conservative in what you send" -- Jon
Postel

Personally, I prefer for people who have no interest in what I'm saying to
politely ignore me rather than confrontationally reject me. That's why I
chair working groups in the IETF.

--
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 exim@www1.ietf.org  Wed Dec 10 16:25:46 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19245
	for <sip-archive@odin.ietf.org>; Wed, 10 Dec 2003 16:25:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUBpb-000819-W4
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 16:25:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBALPFbA030813
	for sip-archive@odin.ietf.org; Wed, 10 Dec 2003 16:25:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUBpP-000802-1n; Wed, 10 Dec 2003 16:25:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUBp2-0007zU-RQ
	for sip@optimus.ietf.org; Wed, 10 Dec 2003 16:24:40 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19182
	for <sip@ietf.org>; Wed, 10 Dec 2003 16:24:37 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUBp0-0002Rs-00
	for sip@ietf.org; Wed, 10 Dec 2003 16:24:38 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUBoz-0002QP-00
	for sip@ietf.org; Wed, 10 Dec 2003 16:24:37 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 10 Dec 2003 13:26:19 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBALO4BN005952;
	Wed, 10 Dec 2003 13:24:05 -0800 (PST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEO55350;
	Wed, 10 Dec 2003 16:24:02 -0500 (EST)
Message-ID: <3FD78EF3.5060206@cisco.com>
Date: Wed, 10 Dec 2003 16:24:03 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Chris Boulton <cboulton@ubiquity.net>
CC: "Drage, Keith (Keith)" <drage@lucent.com>, hisham.khartabil@nokia.com,
        aki.niemi@nokia.com, fluffy@cisco.com, sip@ietf.org
Subject: Re: [Sip] RE: Contact header in PUBLISH
References: <45730E094814E44488F789C1CDED27AE01E22F38@gbnewp0758m.eu.ubiquity.net>
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

I think this has received way more cycles than it needs.
I am happy with either MAY or SHOULD NOT.
Perhaps the argument Aki raised (that SHOULD NOT needs to be accompanied 
by an explanation of the kinds of exceptions that are ok) is a reason to 
prefer MAY. (I don't think we have a prayer of defining the 
circumstances when it might be acceptable.)

	Paul

Chris Boulton wrote:
> I think the 'MAY' option does provide more scope for future extensions.
> You might see a contact, but ignore it.  I understand what Keith is
> saying BUT there is the danger of implementations rejecting on SHOULD
> NOT, even though this is wrong. 
> 
> 
>>-----Original Message-----
>>From: Drage, Keith (Keith) [mailto:drage@lucent.com]
>>Sent: 10 December 2003 14:50
>>To: 'hisham.khartabil@nokia.com'; Drage, Keith (Keith);
>>aki.niemi@nokia.com; pkyzivat@cisco.com
>>Cc: fluffy@cisco.com; sip@ietf.org
>>Subject: RE: [Sip] RE: Contact header in PUBLISH
>>
>>But Paul's text does not disallow, it says SHOULD NOT, not MUST NOT, so
> 
> all
> 
>>recipients must cater for its inclusion, even if they have no use for
> 
> it.
> 
>>regards
>>
>>Keith
>>
>>
>>>-----Original Message-----
>>>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>>>Sent: 10 December 2003 14:31
>>>To: drage@lucent.com; aki.niemi@nokia.com; pkyzivat@cisco.com
>>>Cc: fluffy@cisco.com; sip@ietf.org
>>>Subject: RE: [Sip] RE: Contact header in PUBLISH
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]
>>>>Sent: 10.December.2003 13:39
>>>>To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
>>>>pkyzivat@cisco.com
>>>>Cc: fluffy@cisco.com; sip@ietf.org
>>>>Subject: RE: [Sip] RE: Contact header in PUBLISH
>>>>
>>>>
>>>>If we identify another usage for this header in the future,
>>>>then presumably we need to write another RFC to do it
>>>>superceding the current PUBLISH RFC either fully or in part.
>>>>
>>>>The question we therefore need to ask is whether either text
>>>>has compatibility problems with such a future extension, and
>>>>I believe the answer is no.
>>>
>>>If one RFC disallows something and an extension to it allows
>>>the exact same thing that is disallowed, then we have a
>>>problem. If something is disallowed, it should stay that way,
>>>even in extensions.
>>>
>>>
>>>>I therefore prefer Paul's text, as it leaves fewer unanswered
>>>>questions as to whether I put it in now or not. As regards
>>>>Hisham's current text, I am left with the question of whether
>>>>I should put it in just in case.
>>>
>>>My text (well, Aki's) is clear, you may put contact-header,
>>>but it doesn't buy you anything. Common sense will tell
>>>someone not to include it. Even if you include it, so what?
>>>
>>>Regards,
>>>Hisham
>>>
>>>
>>>>regards
>>>>
>>>>Keith
>>>>
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: hisham.khartabil@nokia.com
>>>>
>>>[mailto:hisham.khartabil@nokia.com]
>>>
>>>>>Sent: 10 December 2003 11:32
>>>>>To: aki.niemi@nokia.com; pkyzivat@cisco.com
>>>>>Cc: fluffy@cisco.com; sip@ietf.org
>>>>>Subject: RE: [Sip] RE: Contact header in PUBLISH
>>>>>
>>>>>
>>>>>You never know what us geniuses might come up with in the
>>>>>future as a possible use for contact-header in PUBLISH. why
>>>>>eliminate this possibility. Including a contact- header in
>>>>>PUBLISH does not break the protocol, so no need to explicitly
>>>>>disallow it. I vote for Aki's original suggestion of using
>>>>>MAY with a slight modification:
>>>>>
>>>>>	PUBLISH request MAY include a Contact header field,
>>>>>although doing so
>>>>>	has no meaning in the PUBLISH context **as defined in
>>>>>this specification**.
>>>>>
>>>>>Regards,
>>>>>Hisham
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
>>>>>>Of ext Aki
>>>>>>Niemi
>>>>>>Sent: 09.December.2003 18:49
>>>>>>To: ext Paul Kyzivat
>>>>>>Cc: fluffy@cisco.com; sip@ietf.org
>>>>>>Subject: Re: [Sip] RE: Contact header in PUBLISH
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>ext Paul Kyzivat wrote:
>>>>>>
>>>>>>>aki.niemi@nokia.com wrote:
>>>>>>>
>>>>>>>
>>>>>>>>PUBLISH is generally never sent in the "other" direction,
>>>>>>>
>>>>>>so I don't
>>>>>>
>>>>>>>>see any reason not to say:
>>>>>>>>
>>>>>>>>    PUBLISH request MAY include a Contact header field,
>>>>>>>
>>>>>>although doing so
>>>>>>
>>>>>>>>    has no meaning in the PUBLISH context.
>>>>>>>>
>>>>>>>>Any other opinions?
>>>>>>>
>>>>>>>
>>>>>>>How about another phrasing that says the same thing but
>>>>>>
>>>>>>emphasizes the
>>>>>>
>>>>>>>desired behavior?
>>>>>>>
>>>>>>>       PUBLISH request SHOULD NOT include a Contact
>>>>>>
>>>>header field.
>>>>
>>>>>>>       Including one has no meaning in the PUBLISH context.
>>>>>>
>>>>>>I'm OK with that, although my understanding is that if we
>>>>>
>>>>>use SHOULD
>>>>>
>>>>>>NOT, we should be attaching some description of the
>>>>>>circumstances where
>>>>>>it would be OK to include it.
>>>>>>
>>>>>>Cheers,
>>>>>>Aki
>>>>>>
>>>>>>
>>>>>>>Paul
>>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>>This list is for NEW development of the core SIP Protocol
>>>>>>Use sip-implementors@cs.columbia.edu for questions on
>>>>>
>>>current sip
>>>
>>>>>>Use sipping@ietf.org for new developments on the
>>>>>
>>>>application of sip
>>>>
>>>>>_______________________________________________
>>>>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>This list is for NEW development of the core SIP Protocol
>>>>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>>Use sipping@ietf.org for new developments on the
>>>>
>>>application of sip
>>>
>>_______________________________________________
>>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>This list is for NEW development of the core SIP Protocol
>>Use sip-implementors@cs.columbia.edu for questions on current sip
>>Use sipping@ietf.org for new developments on the application of sip
> 
> 
> 
> This message has been scanned for viruses by MailControl - www.mailcontrol.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 exim@www1.ietf.org  Thu Dec 11 10:21:04 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05791
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 10:20:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUSc6-0000Sl-TJ
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 10:20:27 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFKQMp001774
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 10:20:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUSbi-0000RE-Uc; Thu, 11 Dec 2003 10:20:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUSbF-0000PZ-Md
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 10:19:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05694
	for <sip@ietf.org>; Thu, 11 Dec 2003 10:19:29 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUSbC-0006FV-00
	for sip@ietf.org; Thu, 11 Dec 2003 10:19:30 -0500
Received: from [62.119.82.43] (helo=hotsip.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUSbC-0006Ez-00
	for sip@ietf.org; Thu, 11 Dec 2003 10:19:30 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Updated gruu mechanism spec
Date: Thu, 11 Dec 2003 16:18:53 +0100
Message-ID: <FE03AFC4B33E7447979123987BD65F450EDAFE@exchange.hotsip.com>
Thread-Topic: [Sip] Updated gruu mechanism spec
Thread-Index: AcO+nW26fYTzsTCnTNSNM1hO8fkfoQBXAXKA
From: "Christian Jansson" <christian.jansson@hotsip.com>
To: "Christian Stredicke" <stredicke@snom.de>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable



> Christian Stredicke wrote:
>
> The client usually closes the TCP connection=20
> after the transaction or a short timeout.=20

That is just your assumption on how a client works. In my mind
it is usually better for the client to keep the TCP connection up
for much longer.

/ Christian Jansson


> That is not ok with=20
> a REGISTER transaction when gruu and NAT is involved.
>=20
> CS
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von=20
> > Jonathan Rosenberg
> > Gesendet: Dienstag, 9. Dezember 2003 13:45
> > An: Christian Stredicke
> > Cc: 'Chris Boulton'; sip@ietf.org
> > Betreff: Re: AW: [Sip] Updated gruu mechanism spec
> >=20
> >=20
> >=20
> > Christian Stredicke wrote:
> >=20
> > > Hi Chris,
> > >
> > > well usually it is a good idea for the UAC to close the TCP
> connection
> > > in order to keep the load on the server low. But in the specific
> case of
> > > obtaining a GRUU (behind NAT) this is not a good=20
> practice; therefore
> I
> > > think it fits well into the GRUU draft.
> >=20
> > Keeping the connection open to the server is a necessary=20
> practice for=20
> > SIP to work through nat, independently of whether you are=20
> using gruus=20
> > or not. As such, I agree with Chris that this kind of=20
> behavior belongs=20
> > in the tcp bcp document that has been discussed on the list.
> >=20
> > -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 exim@www1.ietf.org  Thu Dec 11 11:27:45 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08556
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 11:27:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUTen-0003TW-JC
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 11:27:17 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBGRHPT013355
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 11:27:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUTeX-0003SL-Vs; Thu, 11 Dec 2003 11:27:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUTe5-0003Rg-KC
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 11:26:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08516
	for <sip@ietf.org>; Thu, 11 Dec 2003 11:26:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUTe4-0007no-00
	for sip@ietf.org; Thu, 11 Dec 2003 11:26:32 -0500
Received: from smtp004.mail.ukl.yahoo.com ([217.12.11.35])
	by ietf-mx with smtp (Exim 4.12)
	id 1AUTe4-0007mV-00
	for sip@ietf.org; Thu, 11 Dec 2003 11:26:32 -0500
Received: from unknown (HELO cranberry) (seancolson@12.242.148.169 with login)
  by smtp004.mail.ukl.yahoo.com with SMTP; 11 Dec 2003 16:26:00 -0000
Reply-To: <seancolson@yahoo.com>
From: "Sean Olson" <seancolson@yahoo.com>
To: "'Christian Jansson'" <christian.jansson@hotsip.com>,
        "'Christian Stredicke'" <stredicke@snom.de>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: RE: [Sip] Updated gruu mechanism spec
Date: Thu, 11 Dec 2003 08:26:04 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcO+nW26fYTzsTCnTNSNM1hO8fkfoQBXAXKAAAJ/rmA=
In-Reply-To: <FE03AFC4B33E7447979123987BD65F450EDAFE@exchange.hotsip.com>
Message-Id: <E1AUTe4-0007mV-00@ietf-mx>
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Ditto=20

-----Original Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of =
Christian
Jansson
Sent: Thursday, December 11, 2003 7:19 AM
To: Christian Stredicke; Jonathan Rosenberg
Cc: sip@ietf.org
Subject: RE: [Sip] Updated gruu mechanism spec



> Christian Stredicke wrote:
>
> The client usually closes the TCP connection after the transaction or=20
> a short timeout.

That is just your assumption on how a client works. In my mind it is =
usually
better for the client to keep the TCP connection up for much longer.

/ Christian Jansson


> That is not ok with
> a REGISTER transaction when gruu and NAT is involved.
>=20
> CS
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von=20
> > Jonathan Rosenberg
> > Gesendet: Dienstag, 9. Dezember 2003 13:45
> > An: Christian Stredicke
> > Cc: 'Chris Boulton'; sip@ietf.org
> > Betreff: Re: AW: [Sip] Updated gruu mechanism spec
> >=20
> >=20
> >=20
> > Christian Stredicke wrote:
> >=20
> > > Hi Chris,
> > >
> > > well usually it is a good idea for the UAC to close the TCP
> connection
> > > in order to keep the load on the server low. But in the specific
> case of
> > > obtaining a GRUU (behind NAT) this is not a good
> practice; therefore
> I
> > > think it fits well into the GRUU draft.
> >=20
> > Keeping the connection open to the server is a necessary
> practice for
> > SIP to work through nat, independently of whether you are
> using gruus
> > or not. As such, I agree with Chris that this kind of
> behavior belongs
> > in the tcp bcp document that has been discussed on the list.
> >=20
> > -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


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



From exim@www1.ietf.org  Thu Dec 11 12:11:18 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10277
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 12:11:18 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUUKx-0006TR-Aw
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 12:10:51 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBHApsm024879
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 12:10:51 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUUKA-0006HJ-OL; Thu, 11 Dec 2003 12:10:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUUJV-0006FX-64
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 12:09:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10191
	for <sip@ietf.org>; Thu, 11 Dec 2003 12:09:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUUJT-00011a-00
	for sip@ietf.org; Thu, 11 Dec 2003 12:09:19 -0500
Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly07a.srv.mailcontrol.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUUJT-0000zE-00
	for sip@ietf.org; Thu, 11 Dec 2003 12:09:19 -0500
Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by rly07a.srv.mailcontrol.com (MailControl) with SMTP id hBBH8TiP026773;
	Thu, 11 Dec 2003 17:08:30 GMT
Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net
          via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Thu, 11 Dec 2003 17:11:03 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] Updated gruu mechanism spec
Date: Thu, 11 Dec 2003 17:08:30 -0000
Message-ID: <45730E094814E44488F789C1CDED27AE01E22F3F@gbnewp0758m.eu.ubiquity.net>
Thread-Topic: [Sip] Updated gruu mechanism spec
Thread-Index: AcO+nW26fYTzsTCnTNSNM1hO8fkfoQBXAXKAAAJ/rmAAAXXQAA==
From: "Chris Boulton" <cboulton@ubiquity.net>
To: <seancolson@yahoo.com>, "Christian Jansson" <christian.jansson@hotsip.com>,
        "Christian Stredicke" <stredicke@snom.de>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com)
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

That was my inclination - and the reason for my comment.

>-----Original Message-----
>From: Sean Olson [mailto:seancolson@yahoo.com]
>Sent: 11 December 2003 16:26
>To: 'Christian Jansson'; 'Christian Stredicke'; 'Jonathan Rosenberg'
>Cc: sip@ietf.org
>Subject: RE: [Sip] Updated gruu mechanism spec
>
>Ditto
>
>-----Original Message-----
>From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Christian
>Jansson
>Sent: Thursday, December 11, 2003 7:19 AM
>To: Christian Stredicke; Jonathan Rosenberg
>Cc: sip@ietf.org
>Subject: RE: [Sip] Updated gruu mechanism spec
>
>
>
>> Christian Stredicke wrote:
>>
>> The client usually closes the TCP connection after the transaction or
>> a short timeout.
>
>That is just your assumption on how a client works. In my mind it is
>usually
>better for the client to keep the TCP connection up for much longer.
>
>/ Christian Jansson
>
>
>> That is not ok with
>> a REGISTER transaction when gruu and NAT is involved.
>>
>> CS
>>
>> > -----Urspr=FCngliche Nachricht-----
>> > Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
>> > Jonathan Rosenberg
>> > Gesendet: Dienstag, 9. Dezember 2003 13:45
>> > An: Christian Stredicke
>> > Cc: 'Chris Boulton'; sip@ietf.org
>> > Betreff: Re: AW: [Sip] Updated gruu mechanism spec
>> >
>> >
>> >
>> > Christian Stredicke wrote:
>> >
>> > > Hi Chris,
>> > >
>> > > well usually it is a good idea for the UAC to close the TCP
>> connection
>> > > in order to keep the load on the server low. But in the specific
>> case of
>> > > obtaining a GRUU (behind NAT) this is not a good
>> practice; therefore
>> I
>> > > think it fits well into the GRUU draft.
>> >
>> > Keeping the connection open to the server is a necessary
>> practice for
>> > SIP to work through nat, independently of whether you are
>> using gruus
>> > or not. As such, I agree with Chris that this kind of
>> behavior belongs
>> > in the tcp bcp document that has been discussed on the list.
>> >
>> > -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
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use sip-implementors@cs.columbia.edu for questions on current sip
>Use sipping@ietf.org for new developments on the application of sip


This message has been scanned for viruses by MailControl - www.mailcontrol.=
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 exim@www1.ietf.org  Thu Dec 11 13:34:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13305
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 13:34:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUVdf-0001n2-ED
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 13:34:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBIYFFW006879
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 13:34:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUVdR-0001lp-KU; Thu, 11 Dec 2003 13:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUVcv-0001lI-2E
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 13:33:29 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13286
	for <sip@ietf.org>; Thu, 11 Dec 2003 13:33:26 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUVcs-0003Ob-00
	for sip@ietf.org; Thu, 11 Dec 2003 13:33:27 -0500
Received: from imr2.ericy.com ([198.24.6.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUVcs-0003OA-00
	for sip@ietf.org; Thu, 11 Dec 2003 13:33:26 -0500
Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hBBIWnYb025634;
	Thu, 11 Dec 2003 12:32:49 -0600 (CST)
Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id Y2B8QB4A; Thu, 11 Dec 2003 12:32:37 -0600
Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134])
	by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id hBBIWdbD019895;
	Thu, 11 Dec 2003 13:32:39 -0500 (EST)
Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <XHG62K53>; Thu, 11 Dec 2003 13:32:39 -0500
Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C93DD@lmc37.lmc.ericsson.se>
From: "George Foti (QC/EMC)" <george.foti@ericsson.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, sip@ietf.org
Date: Thu, 11 Dec 2003 13:32:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [Sip] Question on Grid Parameter  in GRUU 01.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi, 

I need some clarification for the intended usage of the grid parameter :
Quoting the draft :

 When placing a GRUU into the Contact header field of a request or
   response, a UA MAY add the "grid" URI parameter to the GRUU. This
   parameter MAY take on any value permitted by the grammar for the
   parameter, but MUST NOT exceed 128 characters. When a UA sends a
   request to the GRUU, the proxy for the domain that owns the GRUU will
   copy this parameter from the GRUU into the Contact URI matching that
   GRUU. This allows the UA to effectively manufacture an infinite
   supply of GRUU, each of which differs by the value of the "grid"
   parameter. When a UA receives a request that was sent to the GRUU, it
   will be able to tell which GRUU was invoked by the "grid" parameter.

So that means that a UA can register a single contact, get back one GRUU from the Registrar.
Then by assigning multiple grid parameters to the GRUU create an equivalent number of different contacts for that UA, the grid being the difference amongst those contacts.
 
Assuming the UA always inserts the grid with contact in its responses or initiated requests.
When the grid is received in a subsequent request, the UA uses the grid to find the intended application associated with that contact.

Is the above understanding right or am I off track.

Thanks
George Foti


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



From exim@www1.ietf.org  Thu Dec 11 13:48:37 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13730
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 13:48:37 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUVr7-0002aQ-ER
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 13:48:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBIm9eO009939
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 13:48:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUVqz-0002Yj-8w; Thu, 11 Dec 2003 13:48:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUVq3-0002Wl-7F
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 13:47:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13643
	for <sip@ietf.org>; Thu, 11 Dec 2003 13:47:00 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUVq0-0003mA-00
	for sip@ietf.org; Thu, 11 Dec 2003 13:47:00 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUVq0-0003kk-00
	for sip@ietf.org; Thu, 11 Dec 2003 13:47:00 -0500
Received: from sj-core-3.cisco.com (171.68.223.137)
  by sj-iport-3.cisco.com with ESMTP; 11 Dec 2003 10:48:51 +0000
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62])
	by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBBIkRrX020702;
	Thu, 11 Dec 2003 10:46:27 -0800 (PST)
Received: from cisco.com ([161.44.79.239])
	by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AEP23048;
	Thu, 11 Dec 2003 13:46:26 -0500 (EST)
Message-ID: <3FD8BB82.7090105@cisco.com>
Date: Thu, 11 Dec 2003 13:46:26 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "George Foti (QC/EMC)" <george.foti@ericsson.com>
CC: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, sip@ietf.org
Subject: Re: [Sip] Question on Grid Parameter  in GRUU 01.txt
References: <2DBF697D5B36014ABA46E66A96107DA02C93DD@lmc37.lmc.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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

George,

Yes, your explanation is right in line with my understanding of the intent.

	Paul

George Foti (QC/EMC) wrote:
> Hi, 
> 
> I need some clarification for the intended usage of the grid parameter :
> Quoting the draft :
> 
>  When placing a GRUU into the Contact header field of a request or
>    response, a UA MAY add the "grid" URI parameter to the GRUU. This
>    parameter MAY take on any value permitted by the grammar for the
>    parameter, but MUST NOT exceed 128 characters. When a UA sends a
>    request to the GRUU, the proxy for the domain that owns the GRUU will
>    copy this parameter from the GRUU into the Contact URI matching that
>    GRUU. This allows the UA to effectively manufacture an infinite
>    supply of GRUU, each of which differs by the value of the "grid"
>    parameter. When a UA receives a request that was sent to the GRUU, it
>    will be able to tell which GRUU was invoked by the "grid" parameter.
> 
> So that means that a UA can register a single contact, get back one GRUU from the Registrar.
> Then by assigning multiple grid parameters to the GRUU create an equivalent number of different contacts for that UA, the grid being the difference amongst those contacts.
>  
> Assuming the UA always inserts the grid with contact in its responses or initiated requests.
> When the grid is received in a subsequent request, the UA uses the grid to find the intended application associated with that contact.
> 
> Is the above understanding right or am I off track.
> 
> Thanks
> George Foti
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Dec 11 15:40:49 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21990
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 15:40:47 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUXab-0007WJ-Qs
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 15:39:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBKdD5A028903
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 15:39:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUXaQ-0007Sm-Va; Thu, 11 Dec 2003 15:39:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUXZf-0007Rt-UQ
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 15:38:15 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21736;
	Thu, 11 Dec 2003 15:38:13 -0500 (EST)
Message-Id: <200312112038.PAA21736@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, 11 Dec 2003 15:38:12 -0500
Subject: [Sip] I-D ACTION:draft-ietf-sip-callee-caps-02.txt
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

--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		: Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-sip-callee-caps-02.txt
	Pages		: 44
	Date		: 2003-12-11
	
This specification defines mechanisms by which a Session Initiation
Protocol (SIP) user agent can convey its capabilities and
characteristics to other user agents. These capabilities are conveyed
as parameters of the Contact header field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-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-callee-caps-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-callee-caps-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:	<2003-12-11160038.I-D@ietf.org>

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

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

Content-Type: text/plain
Content-ID:	<2003-12-11160038.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 exim@www1.ietf.org  Thu Dec 11 16:21:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25545
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 16:21:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYF9-0000fv-Dp
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:21:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLL711002594
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:21:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYF5-0000eD-Sq; Thu, 11 Dec 2003 16:21:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYEr-0000dN-Ea
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 16:20:49 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25475
	for <sip@ietf.org>; Thu, 11 Dec 2003 16:20:46 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYEp-0001Te-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:20:47 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYEp-0001TK-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:20:47 -0500
Received: from dynamicsoft.com ([63.113.46.5])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBBLKLmR000505;
	Thu, 11 Dec 2003 16:20:21 -0500 (EST)
Message-ID: <3FD893E2.6050701@dynamicsoft.com>
Date: Thu, 11 Dec 2003 10:57:22 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Stredicke <stredicke@snom.de>
CC: sip@ietf.org
Subject: Re: AW: AW: [Sip] Updated gruu mechanism spec
References: <021201c3be9d$2dde4470$60fd340a@sip>
In-Reply-To: <021201c3be9d$2dde4470$60fd340a@sip>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mail3.dynamicsoft.com id hBBLKLmR000505
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Yes, I knew you were talking about a client. Its also not OK for the=20
client to close a connection with a REGISTER transaction when gruu=20
isnt' used, if nat is involved. My point was that GRUU changes nothing=20
beyond normal registrations, as far as this problem is concerned.

Thanks,
Jonathan R.

Christian Stredicke wrote:
> Jonathan,
>=20
> if you read carefully you will see that I am talking about the client.
> The client usually closes the TCP connection after the transaction or a
> short timeout. That is not ok with a REGISTER transaction when gruu and
> NAT is involved.
>=20
> CS
>=20
>=20
>>-----Urspr=FCngliche Nachricht-----
>>Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
>>Jonathan Rosenberg
>>Gesendet: Dienstag, 9. Dezember 2003 13:45
>>An: Christian Stredicke
>>Cc: 'Chris Boulton'; sip@ietf.org
>>Betreff: Re: AW: [Sip] Updated gruu mechanism spec
>>
>>
>>
>>Christian Stredicke wrote:
>>
>>
>>>Hi Chris,
>>>
>>>well usually it is a good idea for the UAC to close the TCP
>=20
> connection
>=20
>>>in order to keep the load on the server low. But in the specific
>=20
> case of
>=20
>>>obtaining a GRUU (behind NAT) this is not a good practice; therefore
>=20
> I
>=20
>>>think it fits well into the GRUU draft.
>>
>>Keeping the connection open to the server is a necessary practice for
>>SIP to work through nat, independently of whether you are using gruus
>>or not. As such, I agree with Chris that this kind of behavior belongs
>>in the tcp bcp document that has been discussed on the list.
>>
>>-Jonathan R.
>>
>>
>>--
>>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
>>Chief Technology Officer                    Parsippany, NJ 07054-2711
>>dynamicsoft
>>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>>http://www.jdrosen.net                      PHONE: (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
>=20
>=20

--=20
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Thu Dec 11 16:22:30 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25597
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 16:22:30 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYG2-0000tU-RC
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:22:02 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLM2m0003420
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:22:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYG1-0000sJ-QO; Thu, 11 Dec 2003 16:22:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYF5-0000eE-Uq
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 16:21:03 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25501
	for <sip@ietf.org>; Thu, 11 Dec 2003 16:21:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYF4-0001U2-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:21:02 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYF3-0001TR-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:21:01 -0500
Received: from dynamicsoft.com ([63.113.46.5])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBBLKNmR000508;
	Thu, 11 Dec 2003 16:20:23 -0500 (EST)
Message-ID: <3FD89467.3060106@dynamicsoft.com>
Date: Thu, 11 Dec 2003 10:59:35 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: sip@ietf.org
References: <3FD51161.3090005@cisco.com>
In-Reply-To: <3FD51161.3090005@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: GRUU corner cases
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Thanks for your further comments. Inline.

Paul Kyzivat wrote:

> GRUU is looking pretty good. As I'm reading thru it I am thinking about 
> weird corner cases that might be underspecified.
> 
> Suppose one UA registers its own contact without requesting a GRUU:
> 
>     REGISTER sip:example.com
>     To: sip:foo@example.com
>     From: sip:foo@example.com
>     Expires: 3600
>     Contact: sip:xyz@a.example.com
>     Call-Id: 111@a.example.com
> 
> Then, another UA queries this registration, and then sends its own 
> update to it, requesting a gruu:
> 
>     REGISTER sip:example.com
>     To: sip:foo@example.com
>     From: sip:bar@example.com
>     Supported: gruu
>     Expires: 3600
>     Contact: sip:xyz@a.example.com;gruu
>     Call-Id: 222@a.example.com
 >
> (Assume this is properly authenticated and authorized.) Is this ok?


Requesting a GRUU would not involve placing the gruu parameter in the 
Contact. Presence of "Supported: gruu" is what triggers this. Thus, 
the contact would just be:

Contact: sip:xyz2a.example.com

Besides that, everything is OK so far.

> Then while that registration is still active, suppose there is yet 
> another one:
> 
>     REGISTER sip:example.com
>     To: sip:foo@example.com
>     From: sip:baz@example.com
>     Supported: gruu
>     Expires: 3600
>     Contact: sip:xyz@a.example.com;gruu
>     Call-Id: 333@a.example.com
> 

Same as above - there would not be a gruu parameter in the Contact. In 
this case, the response wouold contain the currently assigned gruu for 
this contact.

> Is that legal too? If so, it could result in the same gruu being given 
> to bar and baz.

Yes. I think this is what you want.

> Is it also ok to give different ones to each? If 
> different ones, does issuing the new one to baz invalidate the one given 
> to bar?

I think the question is, "what is the scope of the gruu"? Is it JUST 
the contact, or is it the combination of the Contact along with the 
call-id, which is used by the registrar to provide a context for 
ordering registrations? i think its just the contact. That is, if a 
different UA (or the same one with a new call-id) refreshes a contact, 
even if the call-id stored by the registrar changes, the gruu remains 
the same.

> 
> In this specific case it probably isn't important what happens. But in 
> general it will be hard for the registrar to distinguish bizare cases 
> like this from more normal cases where things ought to work. In 
> particular, can a registration that doesn't appear to be a refresh 
> invalidate a previously issued gruu?

But, this does appear to be a refresh. Its a refresh because the 
contact exists.

> 
> I think the current intent is that the gruu is required to stick with a 
> particular contact address as long as that is registered, regardless of 
> whether the refresh is technically a refresh from the same source and 
> callid or not.

Correct.

> If so, then everybody receives the same gruu. 

Right.

> That is 
> probably ok. If so, continuing the above scenario, suppose the original 
> ua now refreshes:
> 
>     REGISTER sip:example.com
>     To: sip:foo@example.com
>     From: sip:foo@example.com
>     Expires: 3600
>     Contact: sip:xyz@a.example.com
>     Call-Id: 111@a.example.com
> 
> MUST/SHOULD/MAY the Contact header in the response contain the gruu= 
> parameter? My opinion is that it SHOULD.

I don't think so. This UA doesnt support GRUU. So, the GRUU exists in 
the registrar; its just not returned to the UA.

I think we need some clarification in the spec to cover these cases. I 
have substantially rewritten the section on registrar processing to 
make this more clear. My new text is below; please comment on whether 
this makes more sense than before - I think its much better now. 
Another point that it clarifies is that the gruu is really associated 
with the AOR/Contact pair, not just the Contact. So, if you register 
the same contact to two different AOR, you get two gruus.

> 
> What about the "reg" event package? If a gruu is associated with a 
> particular contact, is that reported in notifications? Does it matter 
> whether the subscriber specifes Supported:gruu or not? IMO the gruu MUST 
> be included if Supported:gruu is present, and SHOULD be present otherwise.

We could add this as an extension to reg-event, since reg-event is 
done. However, when we do, I dont think that we would use "Supported: 
gruu" to indicate that the gruu should be included in the 
notification. This is a filtering function, and should be done either 
in a body part or though an event header parameter. one thing at a 
time though.

> 
> 
> In section 5:
> 
>    ... the GRUU MUST exhibit the
>    following properties:
> 
>    o  When a request is sent to this URI, it routes to a proxy server in
>       the same domain as that of the registrar.
> 
>    o  A proxy server in the domain can determine that the URI is a GRUU.
> 
>    o  When a proxy server in this domain translates this URI, the result
>       is equal to the Contact URI corresponding to the GRUU.
> 
>    o  It MUST NOT be possible, based on inspection of the URI, to
>       determine the associated Contact URI or Address of Record.
> 
> This excludes an interesting special case. It is possible that the 
> registrar can determine that the contact address being registered is 
> already globally routable. If so, it would be good for the registrar to 
> have the option of simply returning the contact address as the gruu. The 
> above criteria exclude that possibility.

Unless the contact being registered is within the domain owned by the 
registrar, the registrar will not have a reliable way of knowing 
whether its globally routable by inspecting the address (even if its a 
public IP, i.e., outside of net-10, 198.162/16, etc., you can't be 
sure). It could presumably run a test, and send an OPTIONS to that 
address from an interface thats known to be on the public Internet. If 
the registrar gets a response to the OPTIONS request, it knows the 
Contact is publically routable.

However, we have also talked about executing features in proxies when 
a request is sent to a gruu (for example, call screening services). 
That capability would be lost. As such, a user would not be able to 
know whether or not server processing has been applied when a request 
arrives, and I think thats a problem.

So, I'm inclined to stick with whats there right now.

> 
> Of course, that would eliminate the privacy advantage of gruus. But we 
> already know that is at best limited. In some cases a UA might prefer 
> the performance advantage of bypassing the proxy if it isn't needed. 
> What about making the requirement to anonymize the gruu an option on the 
> REGISTER?

The problem is that real privacy requires a lot more than just an 
anonymous gruu. There is also masking of varaious header fields, like 
Vias, along with media address hiding.


Here is my proposed new text for the registrar behavior section. 
Please provide comments:

> 5. Registrar Behavior
> 
>    A registrar compliant to this specification is responsible for the
>    creation and maintenance of GRUUs, and for providing those GRUU's to
>    a UA in response to a REGISTER request.
> 
> 5.1 Creation and Maintenance of GRUUs
> 
> 
> 
> 
> Rosenberg                Expires June 10, 2004                  [Page 5]
> 
> Internet-Draft               GRUU Mechanism                December 2003
> 
> 
>    There is a one-to-one mapping between a Contact URI for a particular
>    AOR, and a GRUU. As a result, if two Contact/AOR pairs are different,
>    the GRUU for each MUST be different. If two GRUUs are different, the
>    Contact/AOR pair for those MUST be different. It is important to
>    understand that this uniqueness is over the Contact/AOR pair, not
>    just the Contact. For example, if a user registered the Contact
>    sip:ua@pc.example.com to the AOR sip:user@example.com, and also
>    registered the same Contact - sip:ua@pc.example.com to a second AOR,
>    say sip:boss@example.com, each of those Contacts would have a
>    different GRUU, since they belong to different AORs.
> 
>    A registrar MAY create a GRUU for a particular AOR/Contact pair at
>    any time. Of course, if a UA requests a GRUU in a registration, and
>    the registrar has not yet created one, it will need to do so in order
>    to respond to the registration request. However, the registrar can
>    create the GRUU in advance of any request from a UA.
> 
>    This specification does not mandate a particular mechanism for
>    construction of the GRUU. However, the GRUU MUST exhibit the
>    following properties:
> 
>    o  The domain part of the URI is an IP address present on the public
>       Internet, or, if it is a host name, exists in the global DNS and
>       corresponds to an IP address present on the public Internet.
> 
>    o  When a request is sent to this URI, it routes to a proxy server in
>       the same domain as that of the registrar.
> 
>    o  A proxy server in the domain can determine that the URI is a GRUU.
> 
>    o  When a proxy server in this domain translates this URI, the result
>       is equal to the Contact URI corresponding to the GRUU.
> 
>    o  It MUST NOT be possible, based on inspection of the URI, to
>       determine the associated Contact URI or Address of Record.
> 
>    With these rules, it is possible, though not required, to construct a
>    GRUU without requiring the maintenance of any additional state. To do
>    that, the URI would be constructed in the following fashion:
> 
>       user-part = "GRUU" + BASE64(E(K, (salt + Contact URI + AOR)))
> 
>    Where E(K,X) represents a suitable encryption function (such as AES
>    with 128 bit keys) with key K applied to data block X, and the "+"
>    operator implies concatenation. Salt represents a random string that
>    prevents a client from obtaining pairs of known plaintext and
>    ciphertext. A good choice would be at least 128 bits of randomness in
>    the salt.
> 
> 
> 
> Rosenberg                Expires June 10, 2004                  [Page 6]
> 
> Internet-Draft               GRUU Mechanism                December 2003
> 
> 
>    The benefit of this mechanism is that a server need not store
>    additional information on mapping a GRUU to its corresponding Contact
>    URI. The user part of the GRUU can itself contain the Contact URI.
>    Encryption is needed to prevent attacks whereby the server is sent
>    requests with faked GRUU, causing the server to direct requests to
>    any named URI. Even with encryption, the proxy should validate the
>    user part after decryption. In particular, the AOR should be one
>    managed by the proxy in that domain. Should a UA send a request with
>    a fake GRUU, the proxy would decrypt and then discard it because
>    there would be no URI or an invalid URI inside.
> 
>    Once created, the registrar MUST maintain that GRUU for the duration
>    over which that Contact remains registered to that AOR at the
>    registrar. Furthermore, the registrar MUST NOT change the gruu during
>    that duration. This is true even if the Contact is refreshed from a
>    rebooted or different UA (known by a change in the Call-ID of the
>    REGISTER request). After the Contact expires, the registrar ceases to
>    maintain the binding. The registrar is under no obligation to use the
>    same GRUU should that Contact be re-registered at a later time. Of
>    course, it MAY create the same GRUU if it likes, but this would be an
>    implementation choice.
> 
>    The implication of these rules is that a registrar is responsible for
>    reliable storage of the GRUU for the duration of a registration.
> 
> 5.2 Providing GRUUs to User Agents
> 
>    When a registrar compliant to this specification receives a REGISTER
>    request, it checks for the presence of the Require header field in
>    the request. If present, and if it contains the "gruu" option tag,
>    the registrar MUST follow the procedures in the next paragraph for
>    inclusion of the "gruu" parameter in a 2xx response to REGISTER. If
>    not present, but a Supported header field was present with the "gruu"
>    option tag, the registrar SHOULD follow the procedures in the next
>    paragraph for inclusion of the "gruu" parameter in a 2xx response to
>    REGISTER. If the Supported header field was not present, or it if was
>    present but did not contain the value "gruu", the registrar SHOULD
>    NOT follow the procedures of the next paragraph for inclusion of the
>    "gruu" parameter in a 2xx response to REGISTER.
> 
>    If the register request contained any "gruu" Contact header field
>    parameters, these MUST be ignored by the registrar. A UA cannot
>    suggest or otherwise provide a GRUU to the registrar.
> 
>    A GRUU is provided to a UA by including it in the "gruu" Contact
>    header field parameter for a particular Contact URI. The value of
>    this parameter is a quoted string containing the URI that is the GRUU
>    for the associated Contact URI/AOR pair. If the server does not
> 
> 
> 
> Rosenberg                Expires June 10, 2004                  [Page 7]
> 
> Internet-Draft               GRUU Mechanism                December 2003
> 
> 
>    currently have a GRUU associated with the Contact URI, either because
>    the Contact URI is being newly registered, or because it is being
>    refreshed, but the registrar has not yet computed a GRUU for that
>    Contact, one is created according to the procedures of Section 5.1.
>    Otherwise, if a GRUU already exists for that AOR/Contact pair, the
>    GRUU associated with that pair MUST be placed into the "gruu" Contact
>    header field parameter of the REGISTER response.
> 
>    Inclusion of a GRUU in the "gruu" Contact header field parameter of a
>    REGISTER response is separate from the computation and storage of the
>    GRUU. It is possible that the registrar has computed a GRUU for a
>    contact at the request of one UA, but a different UA that queries for
>    the current set of registrations doesn't understand GRUU. In that
>    case, the REGISTER response sent to that second UA would not contain
>    the "gruu" Contact header field parameter, even though the UA has a
>    GRUU for that Contact.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Thu Dec 11 16:31:36 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26358
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 16:31:36 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYOq-0001X8-Op
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:31:08 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLV8WZ005878
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:31:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYOl-0001Vi-IH; Thu, 11 Dec 2003 16:31:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYOH-0001UN-4V
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 16:30:33 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26288
	for <sip@ietf.org>; Thu, 11 Dec 2003 16:30:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYOF-0001qI-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:30:31 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYOE-0001om-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:30:30 -0500
Received: from dynamicsoft.com ([63.113.46.5])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBBLSKmR000548;
	Thu, 11 Dec 2003 16:28:20 -0500 (EST)
Message-ID: <3FD8E16C.6020001@dynamicsoft.com>
Date: Thu, 11 Dec 2003 16:28:12 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: "George Foti (QC/EMC)" <george.foti@ericsson.com>, sip@ietf.org
Subject: Re: [Sip] Question on Grid Parameter  in GRUU 01.txt
References: <2DBF697D5B36014ABA46E66A96107DA02C93DD@lmc37.lmc.ericsson.se> <3FD8BB82.7090105@cisco.com>
In-Reply-To: <3FD8BB82.7090105@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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Yes, thats the intent. I reworded this text below a bit to clarify 
that the grid appears in the request URI (which is not obvious at all 
from the words below). That aside, is there anything that I can do to 
clarify the intent?

Thanks,
Jonathan R.

Paul Kyzivat wrote:

> George,
> 
> Yes, your explanation is right in line with my understanding of the intent.
> 
>     Paul
> 
> George Foti (QC/EMC) wrote:
> 
>> Hi,
>> I need some clarification for the intended usage of the grid parameter :
>> Quoting the draft :
>>
>>  When placing a GRUU into the Contact header field of a request or
>>    response, a UA MAY add the "grid" URI parameter to the GRUU. This
>>    parameter MAY take on any value permitted by the grammar for the
>>    parameter, but MUST NOT exceed 128 characters. When a UA sends a
>>    request to the GRUU, the proxy for the domain that owns the GRUU will
>>    copy this parameter from the GRUU into the Contact URI matching that
>>    GRUU. This allows the UA to effectively manufacture an infinite
>>    supply of GRUU, each of which differs by the value of the "grid"
>>    parameter. When a UA receives a request that was sent to the GRUU, it
>>    will be able to tell which GRUU was invoked by the "grid" parameter.
>>
>> So that means that a UA can register a single contact, get back one 
>> GRUU from the Registrar.
>> Then by assigning multiple grid parameters to the GRUU create an 
>> equivalent number of different contacts for that UA, the grid being 
>> the difference amongst those contacts.
>>  
>> Assuming the UA always inserts the grid with contact in its responses 
>> or initiated requests.
>> When the grid is received in a subsequent request, the UA uses the 
>> grid to find the intended application associated with that contact.
>>
>> Is the above understanding right or am I off track.
>>
>> Thanks
>> George Foti
>>
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use sip-implementors@cs.columbia.edu for questions on current sip
>> Use sipping@ietf.org for new developments on the application of sip
>>
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Thu Dec 11 16:39:34 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26945
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 16:39:33 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYWY-0002FT-68
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:39:06 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLd6AP008636
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:39:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYWS-0002EQ-UU; Thu, 11 Dec 2003 16:39:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYVu-0002C3-2B
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 16:38:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26837
	for <sip@ietf.org>; Thu, 11 Dec 2003 16:38:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYVs-00024O-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:38:24 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYVr-00023k-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:38:23 -0500
Received: from dynamicsoft.com ([63.113.46.5])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBBLa7mR000560;
	Thu, 11 Dec 2003 16:36:08 -0500 (EST)
Message-ID: <3FD8E33F.6030703@dynamicsoft.com>
Date: Thu, 11 Dec 2003 16:35:59 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
CC: Chris Boulton <cboulton@ubiquity.net>,
        "Drage, Keith (Keith)" <drage@lucent.com>, hisham.khartabil@nokia.com,
        aki.niemi@nokia.com, fluffy@cisco.com, sip@ietf.org
Subject: Re: [Sip] RE: Contact header in PUBLISH
References: <45730E094814E44488F789C1CDED27AE01E22F38@gbnewp0758m.eu.ubiquity.net> <3FD78EF3.5060206@cisco.com>
In-Reply-To: <3FD78EF3.5060206@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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Here's my two cents.

I also prefer SHOULD NOT. Indeed, that is the text currently written 
into the gruu spec when it discusses inclusion of the gruu parameter 
in a REGISTER. Like the Contact in PUBLISH, it is ignored by the 
server. Here is the text:

> Specifically, the Contact URI in the REGISTER request
> SHOULD NOT contain the gruu Contact header field parameter. Any such
> parameters are ignored by the registrar, as the UA cannot propose a
> GRUU for usage with the Contact URI.

I chose SHOULD NOT, since the question was raised on the list about 
whether or not the server would honor the request for the parameter. 
Adding these words makes the intent really clear. I think its 
appropriate for cases where it seems like doing something will 
accomplish a particular behavior, but it won't or shouldn't.

MUST NOT is not appropriate, since violating the text will not cause 
interoperability failures or protocol problems, and thats my 
qualification level for MUST or MUST NOT.

The other choice that makes sense to me is to say NOTHING on the 
client side for publish about COntact, and say that a server MUST 
ignore any Contact present in a request. Thats more appropriate, I 
think, for cases where we don't think people will be confused and try 
to insert it to get a specific behavior.

-Jonathan R.

Paul Kyzivat wrote:

> I think this has received way more cycles than it needs.
> I am happy with either MAY or SHOULD NOT.
> Perhaps the argument Aki raised (that SHOULD NOT needs to be accompanied 
> by an explanation of the kinds of exceptions that are ok) is a reason to 
> prefer MAY. (I don't think we have a prayer of defining the 
> circumstances when it might be acceptable.)
> 
>     Paul
> 
> Chris Boulton wrote:
> 
>> I think the 'MAY' option does provide more scope for future extensions.
>> You might see a contact, but ignore it.  I understand what Keith is
>> saying BUT there is the danger of implementations rejecting on SHOULD
>> NOT, even though this is wrong.
>>
>>> -----Original Message-----
>>> From: Drage, Keith (Keith) [mailto:drage@lucent.com]
>>> Sent: 10 December 2003 14:50
>>> To: 'hisham.khartabil@nokia.com'; Drage, Keith (Keith);
>>> aki.niemi@nokia.com; pkyzivat@cisco.com
>>> Cc: fluffy@cisco.com; sip@ietf.org
>>> Subject: RE: [Sip] RE: Contact header in PUBLISH
>>>
>>> But Paul's text does not disallow, it says SHOULD NOT, not MUST NOT, so
>>
>>
>> all
>>
>>> recipients must cater for its inclusion, even if they have no use for
>>
>>
>> it.
>>
>>> regards
>>>
>>> Keith
>>>
>>>
>>>> -----Original Message-----
>>>> From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com]
>>>> Sent: 10 December 2003 14:31
>>>> To: drage@lucent.com; aki.niemi@nokia.com; pkyzivat@cisco.com
>>>> Cc: fluffy@cisco.com; sip@ietf.org
>>>> Subject: RE: [Sip] RE: Contact header in PUBLISH
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: ext Drage, Keith (Keith) [mailto:drage@lucent.com]
>>>>> Sent: 10.December.2003 13:39
>>>>> To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
>>>>> pkyzivat@cisco.com
>>>>> Cc: fluffy@cisco.com; sip@ietf.org
>>>>> Subject: RE: [Sip] RE: Contact header in PUBLISH
>>>>>
>>>>>
>>>>> If we identify another usage for this header in the future,
>>>>> then presumably we need to write another RFC to do it
>>>>> superceding the current PUBLISH RFC either fully or in part.
>>>>>
>>>>> The question we therefore need to ask is whether either text
>>>>> has compatibility problems with such a future extension, and
>>>>> I believe the answer is no.
>>>>
>>>>
>>>> If one RFC disallows something and an extension to it allows
>>>> the exact same thing that is disallowed, then we have a
>>>> problem. If something is disallowed, it should stay that way,
>>>> even in extensions.
>>>>
>>>>
>>>>> I therefore prefer Paul's text, as it leaves fewer unanswered
>>>>> questions as to whether I put it in now or not. As regards
>>>>> Hisham's current text, I am left with the question of whether
>>>>> I should put it in just in case.
>>>>
>>>>
>>>> My text (well, Aki's) is clear, you may put contact-header,
>>>> but it doesn't buy you anything. Common sense will tell
>>>> someone not to include it. Even if you include it, so what?
>>>>
>>>> Regards,
>>>> Hisham
>>>>
>>>>
>>>>> regards
>>>>>
>>>>> Keith
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: hisham.khartabil@nokia.com
>>>>>
>>>>>
>>>> [mailto:hisham.khartabil@nokia.com]
>>>>
>>>>>> Sent: 10 December 2003 11:32
>>>>>> To: aki.niemi@nokia.com; pkyzivat@cisco.com
>>>>>> Cc: fluffy@cisco.com; sip@ietf.org
>>>>>> Subject: RE: [Sip] RE: Contact header in PUBLISH
>>>>>>
>>>>>>
>>>>>> You never know what us geniuses might come up with in the
>>>>>> future as a possible use for contact-header in PUBLISH. why
>>>>>> eliminate this possibility. Including a contact- header in
>>>>>> PUBLISH does not break the protocol, so no need to explicitly
>>>>>> disallow it. I vote for Aki's original suggestion of using
>>>>>> MAY with a slight modification:
>>>>>>
>>>>>>     PUBLISH request MAY include a Contact header field,
>>>>>> although doing so
>>>>>>     has no meaning in the PUBLISH context **as defined in
>>>>>> this specification**.
>>>>>>
>>>>>> Regards,
>>>>>> Hisham
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf
>>>>>>> Of ext Aki
>>>>>>> Niemi
>>>>>>> Sent: 09.December.2003 18:49
>>>>>>> To: ext Paul Kyzivat
>>>>>>> Cc: fluffy@cisco.com; sip@ietf.org
>>>>>>> Subject: Re: [Sip] RE: Contact header in PUBLISH
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ext Paul Kyzivat wrote:
>>>>>>>
>>>>>>>> aki.niemi@nokia.com wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> PUBLISH is generally never sent in the "other" direction,
>>>>>>>>
>>>>>>>>
>>>>>>> so I don't
>>>>>>>
>>>>>>>>> see any reason not to say:
>>>>>>>>>
>>>>>>>>>    PUBLISH request MAY include a Contact header field,
>>>>>>>>
>>>>>>>>
>>>>>>> although doing so
>>>>>>>
>>>>>>>>>    has no meaning in the PUBLISH context.
>>>>>>>>>
>>>>>>>>> Any other opinions?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> How about another phrasing that says the same thing but
>>>>>>>
>>>>>>>
>>>>>>> emphasizes the
>>>>>>>
>>>>>>>> desired behavior?
>>>>>>>>
>>>>>>>>       PUBLISH request SHOULD NOT include a Contact
>>>>>>>
>>>>>>>
>>>>> header field.
>>>>>
>>>>>>>>       Including one has no meaning in the PUBLISH context.
>>>>>>>
>>>>>>>
>>>>>>> I'm OK with that, although my understanding is that if we
>>>>>>
>>>>>>
>>>>>> use SHOULD
>>>>>>
>>>>>>> NOT, we should be attaching some description of the
>>>>>>> circumstances where
>>>>>>> it would be OK to include it.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Aki
>>>>>>>
>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>>> This list is for NEW development of the core SIP Protocol
>>>>>>> Use sip-implementors@cs.columbia.edu for questions on
>>>>>>
>>>>>>
>>>> current sip
>>>>
>>>>>>> Use sipping@ietf.org for new developments on the
>>>>>>
>>>>>>
>>>>> application of sip
>>>>>
>>>>>> _______________________________________________
>>>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>> This list is for NEW development of the core SIP Protocol
>>>>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>>>>> Use sipping@ietf.org for new developments on the
>>>>>
>>>>>
>>>> application of sip
>>>>
>>> _______________________________________________
>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>> This list is for NEW development of the core SIP Protocol
>>> Use sip-implementors@cs.columbia.edu for questions on current sip
>>> Use sipping@ietf.org for new developments on the application of sip
>>
>>
>>
>>
>> This message has been scanned for viruses by MailControl - 
>> www.mailcontrol.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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Thu Dec 11 16:50:46 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27421
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 16:50:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYhO-0002ls-Ky
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:50:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLoIVs010650
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 16:50:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYh9-0002h7-Li; Thu, 11 Dec 2003 16:50:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUYgz-0002fy-Gz
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 16:49:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27381
	for <sip@ietf.org>; Thu, 11 Dec 2003 16:49:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYgx-0002NU-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:49:51 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUYgw-0002N7-00
	for sip@ietf.org; Thu, 11 Dec 2003 16:49:51 -0500
Received: from dynamicsoft.com ([63.113.46.5])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBBLnPmR000579
	for <sip@ietf.org>; Thu, 11 Dec 2003 16:49:25 -0500 (EST)
Message-ID: <3FD8E65D.8080705@dynamicsoft.com>
Date: Thu, 11 Dec 2003 16:49:17 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] New callee-caps draft
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Folks,

You may have noticed that I put out a new revision of callee-caps. 
This update is based on comments received during IETF last call. Here 
are the changes:

* added support for the "text" media type

* Added forward references in a few places to the section which 
creates the IANA registry for sip media feature tags, to clarify where 
the tags come from

* added a Security Consideratiosn bullet to each of the media feature 
tags definition. This is just a reference to the Security 
Considerations section of callee-caps, which has been significantly 
enhanced.

* significantly expanded the security consideratiosn section. It now 
talks about considerations for the media feature tags independent of 
their usage, and then discusses specific considerations and mecahnisms 
for usage with REGISTER, OPTION, and remote-target URIs

* clarified that new media feature tags are added based on the 
guidelines in RFC 2506 (previously it said they SHOULD be registered 
with IANA)

* Aligned the rules for creating tags in the SIP tree with the IETF 
tree. Namely, they require "IETF consensus", which means an RFC - 
informational or standards track. Previously it required standards track.

* clarified that, if you register a sip.priority feature tag, it 
doesnt mean that your UA *has* to reject calls of lower priority

* And last and not at all least, there was one non-trivial change. 
Turns out that the draft really confused our two uses of media types. 
One use of media types in SIP is in the bodies of SIP messages. The 
other is codec types used in RTP. So, if I say that I support 
"audio/G728", does that mean you can put a body of that type in a SIP 
message when you send it to me? Or, does it mean that I support this 
codec in RTP? Same goes for the "audio", "video", etc. attributes. The 
draft confounded the two meanings.

So, here is where I concluded:

1. the "type" attribute indicates MIME types that can be received in 
SIP messages. so, if you could receive message/sip, you could include 
that. This is consistent with the way the tag is currently defined (it 
already exists in the media feature tag registry)

2. the media feature tags - audio, video, etc. - indicate the 
streaming media types supported. This means they are sip specific, and 
no longer belong in the ietf tree. They are now registered in the sip 
tree. Indeed, the spec now makes all of its registrations in the sip 
tree. None are in the ietf tree.

3. there is no way to indicate support for a specific media codec 
(video/h263). As a result, I removed the text which said that, if you 
register type="video/h263", you also register video=true. If this 
function is really needed (indicated support for specific codecs), we 
can register a parameter in the sip tree for it at any time.


Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Thu Dec 11 17:43:41 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29828
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 17:43:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUZWc-0005NQ-SS
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 17:43:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBMhEMR020609
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 17:43:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUZWQ-0005LQ-4K; Thu, 11 Dec 2003 17:43:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUZVz-0005KW-QI
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 17:42:35 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29730
	for <sip@ietf.org>; Thu, 11 Dec 2003 17:42:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUZVx-00045j-00
	for sip@ietf.org; Thu, 11 Dec 2003 17:42:33 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUZVw-00044f-00
	for sip@ietf.org; Thu, 11 Dec 2003 17:42:33 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 11 Dec 2003 14:44:27 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBBMg0Z0019169;
	Thu, 11 Dec 2003 14:42:01 -0800 (PST)
Received: from [128.107.171.228] ([128.107.171.228])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AKR47794;
	Thu, 11 Dec 2003 14:41:59 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Thu, 11 Dec 2003 14:41:55 -0800
Subject: Re: [Sip] SCTP and TLS
From: Cullen Jennings <fluffy@cisco.com>
To: Adam Roach <adam@dynamicsoft.com>
CC: <sip@ietf.org>
Message-ID: <BBFE32B3.28FA9%fluffy@cisco.com>
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86669@dyn-tx-exch-001.dynamicsoft.com>
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

On 11/25/03 9:10 PM, "Adam Roach" <adam@dynamicsoft.com> wrote:

> Alternately, we could retain backwards compatibility (but have
> people forever wonder about the TCP aberration) by using
> designations like:
> 
> UDP:       SIP/2.0/UDP
> UDP+TLS:   SIP/2.0/TLS/UDP
> TCP:       SIP/2.0/TCP
> TCP+TLS:   SIP/2.0/TLS
> SCTP:      SIP/2.0/SCTP
> SCTP+TLS:  SIP/2.0/TLS/SCTP
> DCCP:      SIP/2.0/DCCP
> DCCP+TLS:  SIP/2.0/TLS/DCCP
> 
> Because of practical considerations, I would propose that the
> second approach is probably the best path forward.
> 
> /a
> 

I think I prefer this too. However, "TLS/DCCP" would not be a valid token so
perhaps it would need to switch the "/" to something that is valid in a
token such as "+" so it would be "TLS+DCCP". I would switch the order (for
no good reason) to be "UDP+DCCP". Agee or am I missing the boat on something
here?

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 exim@www1.ietf.org  Thu Dec 11 22:04:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09128
	for <sip-archive@odin.ietf.org>; Thu, 11 Dec 2003 22:04:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUdbA-0001IQ-PS
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 22:04:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC34Ccl004978
	for sip-archive@odin.ietf.org; Thu, 11 Dec 2003 22:04:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUdb0-00019s-MB; Thu, 11 Dec 2003 22:04:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUdaG-00018s-Bz
	for sip@optimus.ietf.org; Thu, 11 Dec 2003 22:03:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09067
	for <sip@ietf.org>; Thu, 11 Dec 2003 22:03:12 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUdaD-0001YQ-00
	for sip@ietf.org; Thu, 11 Dec 2003 22:03:13 -0500
Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUdaC-0001YN-00
	for sip@ietf.org; Thu, 11 Dec 2003 22:03:12 -0500
Received: from sip (pD9E1013E.dip.t-dialin.net [217.225.1.62])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hBC338BQ026230;
	Fri, 12 Dec 2003 04:03:08 +0100 (MET)
From: "Christian Stredicke" <stredicke@snom.de>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>
Cc: <sip@ietf.org>
Subject: AW: AW: AW: [Sip] Updated gruu mechanism spec
Date: Fri, 12 Dec 2003 04:03:08 +0100
Message-ID: <01bd01c3c05c$78d5d630$2f00a8c0@sip>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <3FD893E2.6050701@dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hmm. Ok I got the point (took a little time...). Let's put it into a
BCP!

Christian

> -----Urspr=FCngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Gesendet: Donnerstag, 11. Dezember 2003 16:57
> An: Christian Stredicke
> Cc: sip@ietf.org
> Betreff: Re: AW: AW: [Sip] Updated gruu mechanism spec
>=20
> Yes, I knew you were talking about a client. Its also not OK for the
> client to close a connection with a REGISTER transaction when gruu
> isnt' used, if nat is involved. My point was that GRUU changes nothing
> beyond normal registrations, as far as this problem is concerned.
>=20
> Thanks,
> Jonathan R.
>=20
> Christian Stredicke wrote:
> > Jonathan,
> >
> > if you read carefully you will see that I am talking about the
client.
> > The client usually closes the TCP connection after the transaction
or a
> > short timeout. That is not ok with a REGISTER transaction when gruu
and
> > NAT is involved.
> >
> > CS
> >
> >
> >>-----Urspr=FCngliche Nachricht-----
> >>Von: sip-admin@ietf.org [mailto:sip-admin@ietf.org] Im Auftrag von
> >>Jonathan Rosenberg
> >>Gesendet: Dienstag, 9. Dezember 2003 13:45
> >>An: Christian Stredicke
> >>Cc: 'Chris Boulton'; sip@ietf.org
> >>Betreff: Re: AW: [Sip] Updated gruu mechanism spec
> >>
> >>
> >>
> >>Christian Stredicke wrote:
> >>
> >>
> >>>Hi Chris,
> >>>
> >>>well usually it is a good idea for the UAC to close the TCP
> >
> > connection
> >
> >>>in order to keep the load on the server low. But in the specific
> >
> > case of
> >
> >>>obtaining a GRUU (behind NAT) this is not a good practice;
therefore
> >
> > I
> >
> >>>think it fits well into the GRUU draft.
> >>
> >>Keeping the connection open to the server is a necessary practice
for
> >>SIP to work through nat, independently of whether you are using
gruus
> >>or not. As such, I agree with Chris that this kind of behavior
belongs
> >>in the tcp bcp document that has been discussed on the list.
> >>
> >>-Jonathan R.
> >>
> >>
> >>--
> >>Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> >>Chief Technology Officer                    Parsippany, NJ
07054-2711
> >>dynamicsoft
> >>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> >>http://www.jdrosen.net                      PHONE: (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
> >
> >
>=20
> --
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Fri Dec 12 03:55:44 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01570
	for <sip-archive@odin.ietf.org>; Fri, 12 Dec 2003 03:55:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUj4t-000852-6a
	for sip-archive@odin.ietf.org; Fri, 12 Dec 2003 03:55:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC8tFP4031000
	for sip-archive@odin.ietf.org; Fri, 12 Dec 2003 03:55:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUj4j-00082m-0c; Fri, 12 Dec 2003 03:55:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUhf0-0004SS-6x
	for sip@optimus.ietf.org; Fri, 12 Dec 2003 02:24:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29499
	for <sip@ietf.org>; Fri, 12 Dec 2003 02:24:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUhew-0006GB-00
	for sip@ietf.org; Fri, 12 Dec 2003 02:24:22 -0500
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUhev-0006G8-00
	for sip@ietf.org; Fri, 12 Dec 2003 02:24:21 -0500
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110])
	by tama5.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hBC7OKUC022658
	for <sip@ietf.org>; Fri, 12 Dec 2003 16:24:20 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1])
	by vcs3.rdh.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hBC7OJpo022249
	for <sip@ietf.org>; Fri, 12 Dec 2003 16:24:20 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69])
	by nttmail3.ecl.ntt.co.jp (8.12.8p1/8.12.8) with ESMTP id hBC7OJ8H021421
	for <sip@ietf.org>; Fri, 12 Dec 2003 16:24:19 +0900 (JST)
Received: from iml.m.ecl.ntt.co.jp (localhost [127.0.0.1])
	by eclscan3.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id QAA20839;
	Fri, 12 Dec 2003 16:24:18 +0900 (JST)
Received: from lab.ntt.co.jp
	by iml.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id QAA05832;
	Fri, 12 Dec 2003 16:24:18 +0900 (JST)
Message-ID: <3FD96CE8.8090309@lab.ntt.co.jp>
Date: Fri, 12 Dec 2003 16:23:20 +0900
From: Yosuke ITOH <itoh.yosuke@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja
MIME-Version: 1.0
To: sip@ietf.org
CC: fukuda.yoshimi@lab.ntt.co.jp, AkiraOno <ono.akira@lab.ntt.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Sip] TCP FIN and SIP crossing
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi,

I have a question of TCP FIN and SIP crossing on wire.
The following sequence actually happened during some of our tests.

 client                   REGISTRAR
1 |----------SYN---------->|
2 |<-------SYN/ACK---------|
3 |----------ACK---------->|
4 |--------REGISTER------->|
5 |<---------401-----------|
6 |-REGISTER->   <-FIN/ACK-|
7 |<-FIN/ACK-   -REGISTER->|
8 |----------ACK---------->|
9 |<-------FIN/ACK---------|
10|<---------ACK-----------|

In this sequence, the REGISTRAR cannot send a "200 OK" because the TCP
connection has already been closed.

Generally, clients are not aware of the state of the TCP connection (open
or closed).

In this situation, a client cannot know that the connection was closed
because the TCP connection was closed normally, without any errors.

One solution is that REGISTRAR sends back a "200 OK" after opening a
new TCP connection.

I would like to know if there is a better way to solve this problem.

Thanks,

Yosuke Itoh

-- 
---------------------------------------------------------
Yosuke Ito,
NTT Network Service Systems Laboratories
3-9-11, Midori-Cho, Musashino-Shi, Tokyo 180-8585 JAPAN
Tel: +81-422-59-7746, Fax: +81-422-59-3494,
e-mail: itoh.yosuke@lab.ntt.co.jp
---------------------------------------------------------



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



From exim@www1.ietf.org  Fri Dec 12 08:41:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08157
	for <sip-archive@odin.ietf.org>; Fri, 12 Dec 2003 08:41:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUnXe-0002kE-TY
	for sip-archive@odin.ietf.org; Fri, 12 Dec 2003 08:41:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCDfEUI010546
	for sip-archive@odin.ietf.org; Fri, 12 Dec 2003 08:41:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUnXS-0002il-BY; Fri, 12 Dec 2003 08:41:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AUnWu-0002fi-F7
	for sip@optimus.ietf.org; Fri, 12 Dec 2003 08:40:28 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08111
	for <sip@ietf.org>; Fri, 12 Dec 2003 08:40:25 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUnWt-000500-00
	for sip@ietf.org; Fri, 12 Dec 2003 08:40:27 -0500
Received: from imr2.ericy.com ([198.24.6.3])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AUnWs-0004xT-00
	for sip@ietf.org; Fri, 12 Dec 2003 08:40:26 -0500
Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52])
	by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id hBCDdfYb016077;
	Fri, 12 Dec 2003 07:39:41 -0600 (CST)
Received: from noah.lmc.ericsson.se ([142.133.1.1]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72)
	id Y2B8TCY7; Fri, 12 Dec 2003 07:39:30 -0600
Received: from EAMMLEX034.lmc.ericsson.se (eammlex034.lmc.ericsson.se [142.133.1.134])
	by noah.lmc.ericsson.se (8.12.10/8.12.10) with ESMTP id hBCDdZbD020556;
	Fri, 12 Dec 2003 08:39:35 -0500 (EST)
Received: by eammlex034.lmc.ericsson.se with Internet Mail Service (5.5.2657.72)
	id <XHG62T8M>; Fri, 12 Dec 2003 08:39:32 -0500
Message-ID: <2DBF697D5B36014ABA46E66A96107DA02C93E0@lmc37.lmc.ericsson.se>
From: "George Foti (QC/EMC)" <george.foti@ericsson.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        Paul Kyzivat
	 <pkyzivat@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] Question on Grid Parameter  in GRUU 01.txt
Date: Fri, 12 Dec 2003 08:39:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I think its fine.
Thanks George

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, December 11, 2003 4:28 PM
> To: Paul Kyzivat
> Cc: George Foti (QC/EMC); sip@ietf.org
> Subject: Re: [Sip] Question on Grid Parameter in GRUU 01.txt
> 
> 
> Yes, thats the intent. I reworded this text below a bit to clarify 
> that the grid appears in the request URI (which is not obvious at all 
> from the words below). That aside, is there anything that I can do to 
> clarify the intent?
> 
> Thanks,
> Jonathan R.
> 
> Paul Kyzivat wrote:
> 
> > George,
> > 
> > Yes, your explanation is right in line with my 
> understanding of the intent.
> > 
> >     Paul
> > 
> > George Foti (QC/EMC) wrote:
> > 
> >> Hi,
> >> I need some clarification for the intended usage of the 
> grid parameter :
> >> Quoting the draft :
> >>
> >>  When placing a GRUU into the Contact header field of a request or
> >>    response, a UA MAY add the "grid" URI parameter to the 
> GRUU. This
> >>    parameter MAY take on any value permitted by the grammar for the
> >>    parameter, but MUST NOT exceed 128 characters. When a UA sends a
> >>    request to the GRUU, the proxy for the domain that owns 
> the GRUU will
> >>    copy this parameter from the GRUU into the Contact URI 
> matching that
> >>    GRUU. This allows the UA to effectively manufacture an infinite
> >>    supply of GRUU, each of which differs by the value of the "grid"
> >>    parameter. When a UA receives a request that was sent 
> to the GRUU, it
> >>    will be able to tell which GRUU was invoked by the 
> "grid" parameter.
> >>
> >> So that means that a UA can register a single contact, get 
> back one 
> >> GRUU from the Registrar.
> >> Then by assigning multiple grid parameters to the GRUU create an 
> >> equivalent number of different contacts for that UA, the 
> grid being 
> >> the difference amongst those contacts.
> >>  
> >> Assuming the UA always inserts the grid with contact in 
> its responses 
> >> or initiated requests.
> >> When the grid is received in a subsequent request, the UA uses the 
> >> grid to find the intended application associated with that contact.
> >>
> >> Is the above understanding right or am I off track.
> >>
> >> Thanks
> >> George Foti
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol
> >> Use sip-implementors@cs.columbia.edu for questions on current sip
> >> Use sipping@ietf.org for new developments on the application of sip
> >>
> > 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Sat Dec 13 01:00:53 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13729
	for <sip-archive@odin.ietf.org>; Sat, 13 Dec 2003 01:00:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AV2pD-0004cL-IA
	for sip-archive@odin.ietf.org; Sat, 13 Dec 2003 01:00:23 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBD60MPx017687
	for sip-archive@odin.ietf.org; Sat, 13 Dec 2003 01:00:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AV2p0-0004aG-8x; Sat, 13 Dec 2003 01:00:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AV2om-0004Z9-HM
	for sip@optimus.ietf.org; Sat, 13 Dec 2003 00:59:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13698
	for <sip@ietf.org>; Sat, 13 Dec 2003 00:59:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AV2oj-0003rI-00
	for sip@ietf.org; Sat, 13 Dec 2003 00:59:53 -0500
Received: from mail4.dynamicsoft.com ([63.110.3.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AV2oj-0003qs-00
	for sip@ietf.org; Sat, 13 Dec 2003 00:59:53 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBD5xGdx000719;
	Fri, 12 Dec 2003 23:59:16 -0600 (CST)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YBTH580S>; Fri, 12 Dec 2003 23:59:15 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866E0@dyn-tx-exch-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Cullen Jennings'" <fluffy@cisco.com>
Cc: sip@ietf.org
Subject: RE: [Sip] SCTP and TLS
Date: Fri, 12 Dec 2003 23:59:09 -0600
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Cullen Jennings [mailto:fluffy@cisco.com] wrote:

> On 11/25/03 9:10 PM, "Adam Roach" <adam@dynamicsoft.com> wrote:
> 
> > Alternately, we could retain backwards compatibility (but have
> > people forever wonder about the TCP aberration) by using
> > designations like:
> > 
> > UDP:       SIP/2.0/UDP
> > UDP+TLS:   SIP/2.0/TLS/UDP
> > TCP:       SIP/2.0/TCP
> > TCP+TLS:   SIP/2.0/TLS
> > SCTP:      SIP/2.0/SCTP
> > SCTP+TLS:  SIP/2.0/TLS/SCTP
> > DCCP:      SIP/2.0/DCCP
> > DCCP+TLS:  SIP/2.0/TLS/DCCP
> > 
> > Because of practical considerations, I would propose that the
> > second approach is probably the best path forward.
> > 
> > /a
> > 
> 
> I think I prefer this too. However, "TLS/DCCP" would not be a 
> valid token

The idea here is to *fix* the syntax, not define new tokens. In
other words, we would redefine "via" to contain:

sent-protocol     =  protocol-name SLASH protocol-version
                     [ SLASH presentation ] [ SLASH session ]
                     SLASH transport

presentation      = token

session           = "TLS" / token

(Hopefully this explains some logic behind my ordering as well).

There aren't any concerns about backwards compatibility for hosts
receiving, say, a "Via" that says "SIP/2.0/TLS/SCTP", because this
very flaw guarantees that no such nodes can exist yet.

/a


P.S. In retrospect, having that "presentation" parameter in there
     to begin with would have made the whole "how do we indicate
     SigComp?" question much more obvious:

     Via: SIP/2.0/SIGCOMP/TLS/TCP 192.168.0.14;branch=z9Hg5bK284921

     Ah, water under the bridge.

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



From exim@www1.ietf.org  Sun Dec 14 12:42:46 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19095
	for <sip-archive@odin.ietf.org>; Sun, 14 Dec 2003 12:42:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVaG3-0006Vw-8t
	for sip-archive@odin.ietf.org; Sun, 14 Dec 2003 12:42:19 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBEHgJ0Y025034
	for sip-archive@odin.ietf.org; Sun, 14 Dec 2003 12:42:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVaFm-0006Up-2M; Sun, 14 Dec 2003 12:42:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AVaEp-0006US-Sj
	for sip@optimus.ietf.org; Sun, 14 Dec 2003 12:41:04 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19052
	for <sip@ietf.org>; Sun, 14 Dec 2003 12:40:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVaEo-0000Fv-00
	for sip@ietf.org; Sun, 14 Dec 2003 12:41:02 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AVaEn-0000Fe-00
	for sip@ietf.org; Sun, 14 Dec 2003 12:41:01 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-3.cisco.com with ESMTP; 14 Dec 2003 09:43:29 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBEHeTAt015269;
	Sun, 14 Dec 2003 09:40:29 -0800 (PST)
Received: from [10.0.1.3] (sjc-vpn4-155.cisco.com [10.21.80.155])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AKS94090;
	Sun, 14 Dec 2003 09:40:28 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Sun, 14 Dec 2003 08:53:54 -0800
Subject: Re: [Sip] SCTP and TLS
From: Cullen Jennings <fluffy@cisco.com>
To: Adam Roach <adam@dynamicsoft.com>
CC: <sip@ietf.org>
Message-ID: <BC01D5A2.29340%fluffy@cisco.com>
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E866E0@dyn-tx-exch-001.dynamicsoft.com>
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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Adam, I don't understand why you are arguing for a delimiter to be a "/"
instead of a "+".  There are things that know how to Parse a VIA that do not
do SCTP or whatever the protocol is. Network sniffers are one, login and
debugging tools that work from log files are another. There are also people
that get that get their SIP stack from a different vendor or internal group
and would need to wait for that group to do this before they could add SCTP
with TLS. Yes, if I was doing it over again, I would do it differently
(including compression). Yet here we are. My goal is to make SIP security
easy enough that someone might actually do it. What is the advantage to
using a "/" over something else that would not break all of the 3261 stuff?

If it is just a perception of having presentation, session, and transport
parameter vs. having one parameter that specifies all three, I have no
problem with a BNF like

sent-protocol     =  protocol-name SLASH protocol-version
                    SLASH transport ["+" session "+" presentation ]

transport = "UDP" / "DCCP" / "TCP" / "SCTP" / token-no-plus

presentation  = "none" / token-no-plus
 
session       = "none" / "TLS" / token-no-plus

token-no-plus =  1*(alphanum / "-" / "." / "!" / "%" / "*"
                     / "_"  / "`" / "'" / "~" )

Personally, I find the presentation session stuff and mapping that to
compression and protocol security layers is taking the OSI model way too
seriously but whatever - not really relevant to the discussion on hand.
There are so few combination of transports, security methods, and other
things we might mix in that I don't really care if we define them as above
or as a list of tokens that result in the same end protocol on the wire as
the stuff above. We are talking syntax sugar one way or the other.

Cullen


PS. I don't like you BNF below because when you get SIP/2.0/foo/TCP you
can't tell if foo is a session or presentation and when you get
SIP/2.0/SIGCOMP/foo/bar you can't tell what foo is until after you see there
is a white space after bar instead of being after foo. I could put this in
much more theoretical impressive sounding terms but you get the idea :-)
 

On 12/12/03 9:59 PM, "Adam Roach" <adam@dynamicsoft.com> wrote:

> Cullen Jennings [mailto:fluffy@cisco.com] wrote:
> 
>> On 11/25/03 9:10 PM, "Adam Roach" <adam@dynamicsoft.com> wrote:
>> 
>>> Alternately, we could retain backwards compatibility (but have
>>> people forever wonder about the TCP aberration) by using
>>> designations like:
>>> 
>>> UDP:       SIP/2.0/UDP
>>> UDP+TLS:   SIP/2.0/TLS/UDP
>>> TCP:       SIP/2.0/TCP
>>> TCP+TLS:   SIP/2.0/TLS
>>> SCTP:      SIP/2.0/SCTP
>>> SCTP+TLS:  SIP/2.0/TLS/SCTP
>>> DCCP:      SIP/2.0/DCCP
>>> DCCP+TLS:  SIP/2.0/TLS/DCCP
>>> 
>>> Because of practical considerations, I would propose that the
>>> second approach is probably the best path forward.
>>> 
>>> /a
>>> 
>> 
>> I think I prefer this too. However, "TLS/DCCP" would not be a
>> valid token
> 
> The idea here is to *fix* the syntax, not define new tokens. In
> other words, we would redefine "via" to contain:
> 
> sent-protocol     =  protocol-name SLASH protocol-version
>                    [ SLASH presentation ] [ SLASH session ]
>                    SLASH transport
> 
> presentation      = token
> 
> session           = "TLS" / token
> 
> (Hopefully this explains some logic behind my ordering as well).
> 
> There aren't any concerns about backwards compatibility for hosts
> receiving, say, a "Via" that says "SIP/2.0/TLS/SCTP", because this
> very flaw guarantees that no such nodes can exist yet.
> 
> /a
> 
> 
> P.S. In retrospect, having that "presentation" parameter in there
>    to begin with would have made the whole "how do we indicate
>    SigComp?" question much more obvious:
> 
>    Via: SIP/2.0/SIGCOMP/TLS/TCP 192.168.0.14;branch=z9Hg5bK284921
> 
>    Ah, water under the bridge.
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Mon Dec 15 17:07:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02866
	for <sip-archive@odin.ietf.org>; Mon, 15 Dec 2003 17:07:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW0rz-0001X4-9w
	for sip-archive@odin.ietf.org; Mon, 15 Dec 2003 17:07:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFM7FGI005824
	for sip-archive@odin.ietf.org; Mon, 15 Dec 2003 17:07:15 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW0rl-0001RI-Kg; Mon, 15 Dec 2003 17:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AW0rB-0001P7-ND
	for sip@optimus.ietf.org; Mon, 15 Dec 2003 17:06:25 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02853
	for <sip@ietf.org>; Mon, 15 Dec 2003 17:06:22 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW0r9-0003Eb-00
	for sip@ietf.org; Mon, 15 Dec 2003 17:06:23 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AW0r8-0003EU-00
	for sip@ietf.org; Mon, 15 Dec 2003 17:06:23 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AW0r8-0003ER-00
	for sip@ietf.org; Mon, 15 Dec 2003 17:06:22 -0500
Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hBFMA2Y4029616
	(version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO);
	Mon, 15 Dec 2003 16:10:02 -0600
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@ietf.org>
Cc: <rohan@cisco.com>,
        "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>
Date: Mon, 15 Dec 2003 16:05:51 -0600
Message-ID: <004401c3c357$9a655890$e1036e3f@txdwillis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] WGLC on RFC 3312 Update
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable


The WG indicated that we thought the 3312 Update Draft was ready to go =
to
WGLC during our meeting in Minneapolis. Therefore, I'm announcing =
Working
Group Last Call on:

http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc3312-update-00.txt

The WGLC will close January 7, 2004.

Please review the draft, and if you have any comments, please respond to =
the
authors. Please copy the list of you think your comments are appropriate =
for
public consumption.

--
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 exim@www1.ietf.org  Wed Dec 17 16:56:45 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07856
	for <sip-archive@odin.ietf.org>; Wed, 17 Dec 2003 16:56:45 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWjeU-0000yN-4q
	for sip-archive@odin.ietf.org; Wed, 17 Dec 2003 16:56:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLuIK6003680
	for sip-archive@odin.ietf.org; Wed, 17 Dec 2003 16:56:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWjeE-0000wJ-Gc; Wed, 17 Dec 2003 16:56:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWjdY-0000vR-Ly
	for sip@optimus.ietf.org; Wed, 17 Dec 2003 16:55:20 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07706
	for <sip@ietf.org>; Wed, 17 Dec 2003 16:55:17 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWjdW-00044J-00
	for sip@ietf.org; Wed, 17 Dec 2003 16:55:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWjdV-000442-00
	for sip@ietf.org; Wed, 17 Dec 2003 16:55:18 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWjdU-00041Z-00
	for sip@ietf.org; Wed, 17 Dec 2003 16:55:16 -0500
Received: from sj-core-5.cisco.com (171.71.177.238)
  by sj-iport-3.cisco.com with ESMTP; 17 Dec 2003 13:58:21 +0000
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBHLsiZ0028455;
	Wed, 17 Dec 2003 13:54:45 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOO85216;
	Wed, 17 Dec 2003 13:54:43 -0800 (PST)
Date: Wed, 17 Dec 2003 13:55:33 -0800
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, rohan@cisco.com,
        dean.willis@softarmor.com (Dean Willis)
To: sip@ietf.org
From: Rohan Mahy <rohan@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <BCFAF0DF-30DB-11D8-95B1-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.553)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Sip] GRUU mechanism document
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hi Folks,

Jonathan updated his GRUU mechanism document based on discussion in 
Minneapolis.  Solving the GRUU problem is very important work.  I 
consider this a high priority because so many other mechanisms depend 
on having GRUUs.

1. Do we want to ask Allison for a Milestone to address GRUU mechanism?

2. If so, do we want Jonathan's draft to be the basis of this mechanism?

Please reply to the list or with one-liners to the chairs.

many 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 exim@www1.ietf.org  Wed Dec 17 19:17:00 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15559
	for <sip-archive@odin.ietf.org>; Wed, 17 Dec 2003 19:17:00 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWlqD-00068l-6P
	for sip-archive@odin.ietf.org; Wed, 17 Dec 2003 19:16:33 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI0GXQS023599
	for sip-archive@odin.ietf.org; Wed, 17 Dec 2003 19:16:33 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWlpj-00066N-KR; Wed, 17 Dec 2003 19:16:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWlow-00064a-Li
	for sip@optimus.ietf.org; Wed, 17 Dec 2003 19:15:14 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15455
	for <sip@ietf.org>; Wed, 17 Dec 2003 19:15:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWlov-0001wV-00
	for sip@ietf.org; Wed, 17 Dec 2003 19:15:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWlou-0001wO-00
	for sip@ietf.org; Wed, 17 Dec 2003 19:15:12 -0500
Received: from mail4.dynamicsoft.com ([63.110.3.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWlot-0001uh-00
	for sip@ietf.org; Wed, 17 Dec 2003 19:15:11 -0500
Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8])
	by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBI0DJA3015219;
	Wed, 17 Dec 2003 18:14:17 -0600 (CST)
Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19)
	id <YBTH6CW4>; Wed, 17 Dec 2003 18:13:19 -0600
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86708@dyn-tx-exch-001.dynamicsoft.com>
From: Adam Roach <adam@dynamicsoft.com>
To: "'Cullen Jennings'" <fluffy@cisco.com>,
        Adam Roach
	 <adam@dynamicsoft.com>
Cc: sip@ietf.org
Subject: RE: [Sip] SCTP and TLS
Date: Wed, 17 Dec 2003 18:13:18 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Okay; I can't bring myself to spend time arguing about this.
Use a plus sign.

/a

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Sunday, December 14, 2003 10:54
> To: Adam Roach
> Cc: sip@ietf.org
> Subject: Re: [Sip] SCTP and TLS
> 
> 
> 
> Adam, I don't understand why you are arguing for a delimiter 
> to be a "/"
> instead of a "+".  There are things that know how to Parse a 
> VIA that do not
> do SCTP or whatever the protocol is. Network sniffers are 
> one, login and
> debugging tools that work from log files are another. There 
> are also people
> that get that get their SIP stack from a different vendor or 
> internal group
> and would need to wait for that group to do this before they 
> could add SCTP
> with TLS. Yes, if I was doing it over again, I would do it differently
> (including compression). Yet here we are. My goal is to make 
> SIP security
> easy enough that someone might actually do it. What is the 
> advantage to
> using a "/" over something else that would not break all of 
> the 3261 stuff?
> 
> If it is just a perception of having presentation, session, 
> and transport
> parameter vs. having one parameter that specifies all three, I have no
> problem with a BNF like
> 
> sent-protocol     =  protocol-name SLASH protocol-version
>                     SLASH transport ["+" session "+" presentation ]
> 
> transport = "UDP" / "DCCP" / "TCP" / "SCTP" / token-no-plus
> 
> presentation  = "none" / token-no-plus
>  
> session       = "none" / "TLS" / token-no-plus
> 
> token-no-plus =  1*(alphanum / "-" / "." / "!" / "%" / "*"
>                      / "_"  / "`" / "'" / "~" )
> 
> Personally, I find the presentation session stuff and mapping that to
> compression and protocol security layers is taking the OSI 
> model way too
> seriously but whatever - not really relevant to the 
> discussion on hand.
> There are so few combination of transports, security methods, 
> and other
> things we might mix in that I don't really care if we define 
> them as above
> or as a list of tokens that result in the same end protocol 
> on the wire as
> the stuff above. We are talking syntax sugar one way or the other.
> 
> Cullen
> 
> 
> PS. I don't like you BNF below because when you get 
> SIP/2.0/foo/TCP you
> can't tell if foo is a session or presentation and when you get
> SIP/2.0/SIGCOMP/foo/bar you can't tell what foo is until 
> after you see there
> is a white space after bar instead of being after foo. I 
> could put this in
> much more theoretical impressive sounding terms but you get 
> the idea :-)
>  
> 
> On 12/12/03 9:59 PM, "Adam Roach" <adam@dynamicsoft.com> wrote:
> 
> > Cullen Jennings [mailto:fluffy@cisco.com] wrote:
> > 
> >> On 11/25/03 9:10 PM, "Adam Roach" <adam@dynamicsoft.com> wrote:
> >> 
> >>> Alternately, we could retain backwards compatibility (but have
> >>> people forever wonder about the TCP aberration) by using
> >>> designations like:
> >>> 
> >>> UDP:       SIP/2.0/UDP
> >>> UDP+TLS:   SIP/2.0/TLS/UDP
> >>> TCP:       SIP/2.0/TCP
> >>> TCP+TLS:   SIP/2.0/TLS
> >>> SCTP:      SIP/2.0/SCTP
> >>> SCTP+TLS:  SIP/2.0/TLS/SCTP
> >>> DCCP:      SIP/2.0/DCCP
> >>> DCCP+TLS:  SIP/2.0/TLS/DCCP
> >>> 
> >>> Because of practical considerations, I would propose that the
> >>> second approach is probably the best path forward.
> >>> 
> >>> /a
> >>> 
> >> 
> >> I think I prefer this too. However, "TLS/DCCP" would not be a
> >> valid token
> > 
> > The idea here is to *fix* the syntax, not define new tokens. In
> > other words, we would redefine "via" to contain:
> > 
> > sent-protocol     =  protocol-name SLASH protocol-version
> >                    [ SLASH presentation ] [ SLASH session ]
> >                    SLASH transport
> > 
> > presentation      = token
> > 
> > session           = "TLS" / token
> > 
> > (Hopefully this explains some logic behind my ordering as well).
> > 
> > There aren't any concerns about backwards compatibility for hosts
> > receiving, say, a "Via" that says "SIP/2.0/TLS/SCTP", because this
> > very flaw guarantees that no such nodes can exist yet.
> > 
> > /a
> > 
> > 
> > P.S. In retrospect, having that "presentation" parameter in there
> >    to begin with would have made the whole "how do we indicate
> >    SigComp?" question much more obvious:
> > 
> >    Via: SIP/2.0/SIGCOMP/TLS/TCP 192.168.0.14;branch=z9Hg5bK284921
> > 
> >    Ah, water under the bridge.
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Thu Dec 18 03:23:46 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11008
	for <sip-archive@odin.ietf.org>; Thu, 18 Dec 2003 03:23:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWtRE-0005rI-He
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 03:23:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI8NGpV022517
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 03:23:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWtR0-0005qD-Nf; Thu, 18 Dec 2003 03:23:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWtQl-0005ph-BL
	for sip@optimus.ietf.org; Thu, 18 Dec 2003 03:22:47 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10982
	for <sip@ietf.org>; Thu, 18 Dec 2003 03:22:45 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWtQj-0005aF-00
	for sip@ietf.org; Thu, 18 Dec 2003 03:22:45 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWtQi-0005a8-00
	for sip@ietf.org; Thu, 18 Dec 2003 03:22:44 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWtQh-0005a5-00
	for sip@ietf.org; Thu, 18 Dec 2003 03:22:43 -0500
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI8MhI28198
	for <sip@ietf.org>; Thu, 18 Dec 2003 10:22:43 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T669544921aac158f2492c@esvir04nok.ntc.nokia.com> for <sip@ietf.org>;
 Thu, 18 Dec 2003 10:22:43 +0200
Received: from nokia.com ([172.17.140.186]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 18 Dec 2003 10:22:42 +0200
Message-ID: <3FE163D1.1030001@nokia.com>
Date: Thu, 18 Dec 2003 10:22:41 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'sip@ietf.org'" <sip@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Dec 2003 08:22:42.0212 (UTC) FILETIME=[1B3DCE40:01C3C540]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Sip] PUBLISH and presence compositor policy
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

All,

There's one more issue with regards to PUBLISH, related to presence 
publication. I've talked with our implementors, and the issue also came 
up in the recent SIMPLEt event. Currently, composer policy for presence 
seems underspecified, namely that the PUBLISH draft doesn't talk about 
how the composer should treat the published tuples, and also gives few 
tools for creating such policy.

For example:

- EPA publishes three tuples {X, Y, Z}, and receives etag Q for it
- EPA modifies publication that matches 'Q', by sending two tuples
   {X', Y'}

How can the ESC determine which tuples were just dropped, which ones 
were modified/unmodified, and which ones are completely new ones?

The easy answer to this is of course to use the tuple-ids, but we don't 
mandate that the EPA keeps the tuple-ids consistent in its modifying 
publications. It could generate new tuple-ids for all of the tuples in 
each round of modification.

All of this makes composer policy more complex, and especially 
implementing partial-notify unnecessarily hard.

So my proposal is to add the following text to Chapter 4 "Considerations 
for Event Packages using PUBLISH":

    In presence publication, the EPA MUST keep the tuple-ids
    consistent within a publication cycle. If a particular tuple
    is modified, it MUST maintain its original tuple-id.
    Similarly, if a tuple is added, its tuple-id MUST NOT concide
    with a tuple that is deleted. A publication cycle begins with
    an initial publication, and ends when either the publication
    expires, or is explicitly removed.

While this doesn't spell out what a presence composer policy should be, 
it at least gives the composer more tools for deriving from an incoming 
publication the type of state change that occurred, and where exactly it 
occurred.

Thoughts?

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 exim@www1.ietf.org  Thu Dec 18 07:04:39 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16886
	for <sip-archive@odin.ietf.org>; Thu, 18 Dec 2003 07:04:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWwt3-0005HV-Ft
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 07:04:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIC4D8I020300
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 07:04:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWwsr-0005GL-Qn; Thu, 18 Dec 2003 07:04:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWwsI-0005Eq-Jt
	for sip@optimus.ietf.org; Thu, 18 Dec 2003 07:03:26 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16829
	for <sip@ietf.org>; Thu, 18 Dec 2003 07:03:22 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWwsE-0003OE-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:03:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWwsD-0003O7-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:03:21 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWwsC-0003O4-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:03:20 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBIC3Lt05529
	for <sip@ietf.org>; Thu, 18 Dec 2003 14:03:21 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T66960e8fafac158f23078@esvir03nok.nokia.com> for <sip@ietf.org>;
 Thu, 18 Dec 2003 14:03:20 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 18 Dec 2003 14:03:20 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] PUBLISH and presence compositor policy
Date: Thu, 18 Dec 2003 14:03:20 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B156@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] PUBLISH and presence compositor policy
Thread-Index: AcPFQKMqVJ9zhvz2TECH3mx0najI6gAHYhsA
To: <aki.niemi@nokia.com>, <sip@ietf.org>
X-OriginalArrivalTime: 18 Dec 2003 12:03:20.0657 (UTC) FILETIME=[EDF83410:01C3C55E]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable



> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf=20
> Of ext Aki
> Niemi
> Sent: 18.December.2003 10:23
> To: 'sip@ietf.org'
> Subject: [Sip] PUBLISH and presence compositor policy
>=20
>=20
> All,
>=20
> There's one more issue with regards to PUBLISH, related to presence=20
> publication. I've talked with our implementors, and the issue=20
> also came=20
> up in the recent SIMPLEt event. Currently, composer policy=20
> for presence=20
> seems underspecified, namely that the PUBLISH draft doesn't=20
> talk about=20
> how the composer should treat the published tuples, and also=20
> gives few=20
> tools for creating such policy.
>=20
> For example:
>=20
> - EPA publishes three tuples {X, Y, Z}, and receives etag Q for it
> - EPA modifies publication that matches 'Q', by sending two tuples
>    {X', Y'}
>=20
> How can the ESC determine which tuples were just dropped, which ones=20
> were modified/unmodified, and which ones are completely new ones?
>=20
> The easy answer to this is of course to use the tuple-ids,=20
> but we don't=20
> mandate that the EPA keeps the tuple-ids consistent in its modifying=20
> publications. It could generate new tuple-ids for all of the=20
> tuples in=20
> each round of modification.
>=20
> All of this makes composer policy more complex, and especially=20
> implementing partial-notify unnecessarily hard.
>=20
> So my proposal is to add the following text to Chapter 4=20
> "Considerations=20
> for Event Packages using PUBLISH":
>=20
>     In presence publication, the EPA MUST keep the tuple-ids
>     consistent within a publication cycle. If a particular tuple
>     is modified, it MUST maintain its original tuple-id.
>     Similarly, if a tuple is added, its tuple-id MUST NOT concide
>     with a tuple that is deleted. A publication cycle begins with
>     an initial publication, and ends when either the publication
>     expires, or is explicitly removed.

These were might thoughts as well. The issue of deleting tuples still =
remains. What does it mean if an EPA doesn't include a tuple in a =
PUBLISH refresh? Is it deleted? I would say no. You don't want every =
PUBLISH refresh to carry the same number of tuples. So we need a way to =
explicitly remove tuples.

This kinda mandates partial publishing.

/Hisham

>=20
> While this doesn't spell out what a presence composer policy=20
> should be,=20
> it at least gives the composer more tools for deriving from=20
> an incoming=20
> publication the type of state change that occurred, and where=20
> exactly it=20
> occurred.
>=20
> Thoughts?
>=20
> Cheers,
> Aki
>=20
>=20
>=20
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>=20

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



From exim@www1.ietf.org  Thu Dec 18 07:21:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17227
	for <sip-archive@odin.ietf.org>; Thu, 18 Dec 2003 07:21:43 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWx9V-0006RR-EM
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 07:21:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBICLD05024701
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 07:21:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWx9L-0006KW-3y; Thu, 18 Dec 2003 07:21:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWx9E-0006Js-Ti
	for sip@optimus.ietf.org; Thu, 18 Dec 2003 07:20:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17204
	for <sip@ietf.org>; Thu, 18 Dec 2003 07:20:55 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWx9E-0003rh-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:20:56 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWx9C-0003rX-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:20:55 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWx9B-0003rN-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:20:54 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBICKqt00344
	for <sip@ietf.org>; Thu, 18 Dec 2003 14:20:52 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T66961e988bac158f23078@esvir03nok.nokia.com> for <sip@ietf.org>;
 Thu, 18 Dec 2003 14:20:51 +0200
Received: from nokia.com ([172.17.140.186]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 18 Dec 2003 14:20:50 +0200
Message-ID: <3FE19BA1.3020309@nokia.com>
Date: Thu, 18 Dec 2003 14:20:49 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Khartabil Hisham (NMP-MSW/Helsinki)" <hisham.khartabil@nokia.com>
CC: sip@ietf.org, "Lonnfors Mikko (NRC/Helsinki)" <mikko.lonnfors@nokia.com>
Subject: Re: [Sip] PUBLISH and presence compositor policy
References: <2038BCC78B1AD641891A0D1AE133DBB70118B156@esebe019.ntc.nokia.com>
In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B156@esebe019.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Dec 2003 12:20:50.0554 (UTC) FILETIME=[5FC1C5A0:01C3C561]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Khartabil Hisham (NMP-MSW/Helsinki) wrote:

>> So my proposal is to add the following text to Chapter 4 
>> "Considerations for Event Packages using PUBLISH":
>> 
>> In presence publication, the EPA MUST keep the tuple-ids consistent
>> within a publication cycle. If a particular tuple is modified, it
>> MUST maintain its original tuple-id. Similarly, if a tuple is
>> added, its tuple-id MUST NOT concide with a tuple that is deleted.
>> A publication cycle begins with an initial publication, and ends
>> when either the publication expires, or is explicitly removed.
> 
> 
> These were might thoughts as well. The issue of deleting tuples still
> remains. What does it mean if an EPA doesn't include a tuple in a
> PUBLISH refresh? Is it deleted? I would say no. 

I disagree. I really think all PUBLISH requests should have 'replace' 
semantics. That is, each modifying publication (i.e., a PUBLISH with a 
valid etag and a body of event state) replaces the previously published 
state associated with that particular etag. Now the issue is really how 
the composer determines what sort of a replacement it was.

So to delete a tuple, the EPA simply omits it from a PUBLISH. So if a 
tuple-id is missing compared to the previous publication, it is 
"deleted", i.e., missing relative to the existing state associated with 
the etag.

> You don't want every
> PUBLISH refresh to carry the same number of tuples. So we need a way
> to explicitly remove tuples.
> 
> This kinda mandates partial publishing.

I agree with your thoughts about needing partial publishing to save 
bandwidth with the publications. But I see no reason why this can't be a 
function of the body which carries the event state (as it is in 
presence). In fact, for presence, we ought to be able to use 
"application/pidf-partial+xml" straight out of the box?

Cheers,
Aki

> /Hisham
> 
> 
>> While this doesn't spell out what a presence composer policy should
>> be, it at least gives the composer more tools for deriving from an
>> incoming publication the type of state change that occurred, and
>> where exactly it occurred.
>> 
>> Thoughts?
>> 
>> 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 exim@www1.ietf.org  Thu Dec 18 07:51:44 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18355
	for <sip-archive@odin.ietf.org>; Thu, 18 Dec 2003 07:51:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWxcZ-0008BL-A1
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 07:51:15 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBICpEUe031391
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 07:51:14 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWxcN-00084H-CT; Thu, 18 Dec 2003 07:51:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWxbr-0007zz-Dp
	for sip@optimus.ietf.org; Thu, 18 Dec 2003 07:50:31 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18314
	for <sip@ietf.org>; Thu, 18 Dec 2003 07:50:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWxbq-00056R-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:50:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWxbp-00056K-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:50:30 -0500
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWxbp-00052W-00
	for sip@ietf.org; Thu, 18 Dec 2003 07:50:29 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-2.cisco.com with ESMTP; 18 Dec 2003 04:53:20 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBICnuAt006521
	for <sip@ietf.org>; Thu, 18 Dec 2003 04:49:56 -0800 (PST)
Received: from [10.32.245.155] (stealth-10-32-245-155.cisco.com [10.32.245.155])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with SMTP id AKW05027;
	Thu, 18 Dec 2003 04:49:54 -0800 (PST)
Date: Thu, 18 Dec 2003 07:49:53 -0500
From: David Oran <oran@cisco.com>
To: sip@ietf.org
Subject: Re: [Sip] GRUU mechanism document
Message-ID: <2147483647.1071733793@[10.32.245.155]>
In-Reply-To: <BCFAF0DF-30DB-11D8-95B1-0003938AF740@cisco.com>
References: <BCFAF0DF-30DB-11D8-95B1-0003938AF740@cisco.com>
X-Mailer: Mulberry/3.1.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

> 1. Do we want to ask Allison for a Milestone to address GRUU mechanism?
>
Yes

> 2. If so, do we want Jonathan's draft to be the basis of this mechanism?
>
Yes.


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



From exim@www1.ietf.org  Thu Dec 18 09:02:41 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22302
	for <sip-archive@odin.ietf.org>; Thu, 18 Dec 2003 09:02:41 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWyjF-0003Ez-9Y
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 09:02:13 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIE2DDn012454
	for sip-archive@odin.ietf.org; Thu, 18 Dec 2003 09:02:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWyj2-0003Du-VC; Thu, 18 Dec 2003 09:02:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AWyiV-0003DF-Cs
	for sip@optimus.ietf.org; Thu, 18 Dec 2003 09:01:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22208
	for <sip@ietf.org>; Thu, 18 Dec 2003 09:01:25 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWyiT-0002FS-00
	for sip@ietf.org; Thu, 18 Dec 2003 09:01:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AWyiS-0002FL-00
	for sip@ietf.org; Thu, 18 Dec 2003 09:01:25 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AWyiS-0002FH-00
	for sip@ietf.org; Thu, 18 Dec 2003 09:01:24 -0500
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBIE1Nt05629
	for <sip@ietf.org>; Thu, 18 Dec 2003 16:01:23 +0200 (EET)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T66967a9f86ac158f2492c@esvir04nok.ntc.nokia.com> for <sip@ietf.org>;
 Thu, 18 Dec 2003 16:01:22 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Thu, 18 Dec 2003 16:01:17 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] PUBLISH and presence compositor policy
Date: Thu, 18 Dec 2003 16:01:20 +0200
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B157@esebe019.ntc.nokia.com>
Thread-Topic: [Sip] PUBLISH and presence compositor policy
Thread-Index: AcPFYWA/Y2dJc7r1R02j2QSMmc9MnAADUI9Q
To: <aki.niemi@nokia.com>
Cc: <sip@ietf.org>, <mikko.lonnfors@nokia.com>
X-OriginalArrivalTime: 18 Dec 2003 14:01:17.0156 (UTC) FILETIME=[67E44240:01C3C56F]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable



> -----Original Message-----
> From: Aki Niemi [mailto:aki.niemi@nokia.com]
> Sent: 18.December.2003 14:21
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: sip@ietf.org; Lonnfors Mikko (NRC/Helsinki)
> Subject: Re: [Sip] PUBLISH and presence compositor policy
>=20
>=20
>=20
>=20
> Khartabil Hisham (NMP-MSW/Helsinki) wrote:
>=20
> >> So my proposal is to add the following text to Chapter 4=20
> >> "Considerations for Event Packages using PUBLISH":
> >>=20
> >> In presence publication, the EPA MUST keep the tuple-ids consistent
> >> within a publication cycle. If a particular tuple is modified, it
> >> MUST maintain its original tuple-id. Similarly, if a tuple is
> >> added, its tuple-id MUST NOT concide with a tuple that is deleted.
> >> A publication cycle begins with an initial publication, and ends
> >> when either the publication expires, or is explicitly removed.
> >=20
> >=20
> > These were might thoughts as well. The issue of deleting=20
> tuples still
> > remains. What does it mean if an EPA doesn't include a tuple in a
> > PUBLISH refresh? Is it deleted? I would say no.=20
>=20
> I disagree. I really think all PUBLISH requests should have 'replace'=20
> semantics. That is, each modifying publication (i.e., a=20
> PUBLISH with a=20
> valid etag and a body of event state) replaces the previously=20
> published=20
> state associated with that particular etag. Now the issue is=20
> really how=20
> the composer determines what sort of a replacement it was.
>=20
> So to delete a tuple, the EPA simply omits it from a PUBLISH. So if a=20
> tuple-id is missing compared to the previous publication, it is=20
> "deleted", i.e., missing relative to the existing state=20
> associated with=20
> the etag.

Sorry, I didn't make my point very clear. I was talking about partial =
publishing, not full publishing. I agree with your statement above.

>=20
> > You don't want every
> > PUBLISH refresh to carry the same number of tuples. So we need a way
> > to explicitly remove tuples.
> >=20
> > This kinda mandates partial publishing.
>=20
> I agree with your thoughts about needing partial publishing to save=20
> bandwidth with the publications. But I see no reason why this=20
> can't be a=20
> function of the body which carries the event state (as it is in=20
> presence). In fact, for presence, we ought to be able to use=20
> "application/pidf-partial+xml" straight out of the box?

I don't see any reason why not.

/Hisham

>=20
> Cheers,
> Aki
>=20
> > /Hisham
> >=20
> >=20
> >> While this doesn't spell out what a presence composer policy should
> >> be, it at least gives the composer more tools for deriving from an
> >> incoming publication the type of state change that occurred, and
> >> where exactly it occurred.
> >>=20
> >> Thoughts?
> >>=20
> >> Cheers, Aki
> >>=20
> >>=20
> >>=20
> >> _______________________________________________ Sip mailing list
> >> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW
> >> development of the core SIP Protocol Use
> >> sip-implementors@cs.columbia.edu for questions on current sip Use
> >> sipping@ietf.org for new developments on the application of sip
> >=20
> >=20
>=20

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



From exim@www1.ietf.org  Fri Dec 19 04:59:52 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01096
	for <sip-archive@odin.ietf.org>; Fri, 19 Dec 2003 04:59:52 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXHPo-00010b-ER
	for sip-archive@odin.ietf.org; Fri, 19 Dec 2003 04:59:24 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ9xONI003876
	for sip-archive@odin.ietf.org; Fri, 19 Dec 2003 04:59:24 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXHPV-0000zC-HF; Fri, 19 Dec 2003 04:59:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXHOZ-0000xb-GF
	for sip@optimus.ietf.org; Fri, 19 Dec 2003 04:58:07 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00968
	for <sip@ietf.org>; Fri, 19 Dec 2003 04:58:03 -0500 (EST)
From: mikko.lonnfors@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXHOV-0003X2-00
	for sip@ietf.org; Fri, 19 Dec 2003 04:58:03 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXHOU-0003Wv-00
	for sip@ietf.org; Fri, 19 Dec 2003 04:58:02 -0500
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXHOT-0003Ws-00
	for sip@ietf.org; Fri, 19 Dec 2003 04:58:01 -0500
Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37])
	by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJ9w2Z07584
	for <sip@ietf.org>; Fri, 19 Dec 2003 11:58:02 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T669abcc3f0ac158f2568f@esvir05nok.ntc.nokia.com> for <sip@ietf.org>;
 Fri, 19 Dec 2003 11:52:06 +0200
Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 19 Dec 2003 11:52:05 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] PUBLISH and presence compositor policy
Date: Fri, 19 Dec 2003 11:52:05 +0200
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17278@esebe004.ntc.nokia.com>
Thread-Topic: [Sip] PUBLISH and presence compositor policy
Thread-Index: AcPFYWBQV6Npipo8RvmelXi9t7dt0gAsmLNg
To: <aki.niemi@nokia.com>, <hisham.khartabil@nokia.com>
Cc: <sip@ietf.org>
X-OriginalArrivalTime: 19 Dec 2003 09:52:05.0889 (UTC) FILETIME=[C2A7B710:01C3C615]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Inline

> -----Original Message-----
> From: Aki Niemi [mailto:aki.niemi@nokia.com]=20
> Sent: Thursday, December 18, 2003 2:21 PM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: sip@ietf.org; Lonnfors Mikko (NRC/Helsinki)
> Subject: Re: [Sip] PUBLISH and presence compositor policy
>=20
>=20
>=20
>=20
> Khartabil Hisham (NMP-MSW/Helsinki) wrote:
>=20
> >> So my proposal is to add the following text to Chapter 4
> >> "Considerations for Event Packages using PUBLISH":
> >>=20
> >> In presence publication, the EPA MUST keep the tuple-ids=20
> consistent=20
> >> within a publication cycle. If a particular tuple is modified, it=20
> >> MUST maintain its original tuple-id. Similarly, if a tuple=20
> is added,=20
> >> its tuple-id MUST NOT concide with a tuple that is deleted. A=20
> >> publication cycle begins with an initial publication, and=20
> ends when=20
> >> either the publication expires, or is explicitly removed.
> >=20
> >=20
> > These were might thoughts as well. The issue of deleting=20
> tuples still=20
> > remains. What does it mean if an EPA doesn't include a tuple in a=20
> > PUBLISH refresh? Is it deleted? I would say no.
>=20
> I disagree. I really think all PUBLISH requests should have 'replace'=20
> semantics. That is, each modifying publication (i.e., a=20
> PUBLISH with a=20
> valid etag and a body of event state) replaces the previously=20
> published=20
> state associated with that particular etag. Now the issue is=20
> really how=20
> the composer determines what sort of a replacement it was.
>=20
> So to delete a tuple, the EPA simply omits it from a PUBLISH. So if a=20
> tuple-id is missing compared to the previous publication, it is=20
> "deleted", i.e., missing relative to the existing state=20
> associated with=20
> the etag.
>=20
> > You don't want every
> > PUBLISH refresh to carry the same number of tuples. So we=20
> need a way=20
> > to explicitly remove tuples.
> >=20
> > This kinda mandates partial publishing.
>=20
> I agree with your thoughts about needing partial publishing to save=20
> bandwidth with the publications. But I see no reason why this=20
> can't be a=20
> function of the body which carries the event state (as it is in=20
> presence). In fact, for presence, we ought to be able to use=20
> "application/pidf-partial+xml" straight out of the box?

'application/pidf-partial+xml' should work 'out of the box'. However, I
think there are some issues which needs to be documented if you want to
do that. Draft-ietf-simple-partial-notify specifies how
'application/pidf-partial+xml' is used with SUB/NOT i.e. when watcher
and PS should use 'full' and 'partial' state notifications. I think
something similar is needed if you want to use this with PUBLISH. In
practice this probably means documenting how EAP should use 'full' and
'partial' state in the context of etag.

- Mikko

> Cheers,
> Aki
>=20
> > /Hisham
> >=20
> >=20
> >> While this doesn't spell out what a presence composer=20
> policy should=20
> >> be, it at least gives the composer more tools for deriving from an=20
> >> incoming publication the type of state change that occurred, and=20
> >> where exactly it occurred.
> >>=20
> >> Thoughts?
> >>=20
> >> Cheers, Aki
> >>=20
> >>=20
> >>=20
> >> _______________________________________________ Sip mailing list=20
> >> https://www1.ietf.org/mailman/listinfo/sip This list is for NEW=20
> >> development of the core SIP Protocol Use=20
> >> sip-implementors@cs.columbia.edu for questions on current sip Use=20
> >> sipping@ietf.org for new developments on the application of sip
> >=20
> >=20
>=20

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



From exim@www1.ietf.org  Fri Dec 19 07:01:44 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05004
	for <sip-archive@odin.ietf.org>; Fri, 19 Dec 2003 07:01:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXJJm-0004xp-CX
	for sip-archive@odin.ietf.org; Fri, 19 Dec 2003 07:01:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJC1IBF019080
	for sip-archive@odin.ietf.org; Fri, 19 Dec 2003 07:01:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXJJX-0004wM-Dd; Fri, 19 Dec 2003 07:01:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXJIj-0004v2-DI
	for sip@optimus.ietf.org; Fri, 19 Dec 2003 07:00:13 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04950
	for <sip@ietf.org>; Fri, 19 Dec 2003 07:00:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXJId-0007JJ-00
	for sip@ietf.org; Fri, 19 Dec 2003 07:00:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXJIb-0007Ix-00
	for sip@ietf.org; Fri, 19 Dec 2003 07:00:07 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXJIb-0007Il-00
	for sip@ietf.org; Fri, 19 Dec 2003 07:00:05 -0500
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJC04U15774
	for <sip@ietf.org>; Fri, 19 Dec 2003 14:00:05 +0200 (EET)
Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T669b31edb5ac158f23078@esvir03nok.nokia.com> for <sip@ietf.org>;
 Fri, 19 Dec 2003 14:00:04 +0200
Received: from nokia.com ([172.21.11.106]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Fri, 19 Dec 2003 14:00:04 +0200
Message-ID: <3FE2E844.7060302@nokia.com>
Date: Fri, 19 Dec 2003 14:00:04 +0200
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ext mikko.lonnfors@nokia.com" <mikko.lonnfors@nokia.com>
CC: hisham.khartabil@nokia.com, sip@ietf.org
Subject: Re: [Sip] PUBLISH and presence compositor policy
References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17278@esebe004.ntc.nokia.com>
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17278@esebe004.ntc.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Dec 2003 12:00:04.0524 (UTC) FILETIME=[A37A6EC0:01C3C627]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



ext mikko.lonnfors@nokia.com wrote:

>>I agree with your thoughts about needing partial publishing to save 
>>bandwidth with the publications. But I see no reason why this 
>>can't be a 
>>function of the body which carries the event state (as it is in 
>>presence). In fact, for presence, we ought to be able to use 
>>"application/pidf-partial+xml" straight out of the box?
> 
> 
> 'application/pidf-partial+xml' should work 'out of the box'. However, I
> think there are some issues which needs to be documented if you want to
> do that. Draft-ietf-simple-partial-notify specifies how
> 'application/pidf-partial+xml' is used with SUB/NOT i.e. when watcher
> and PS should use 'full' and 'partial' state notifications. I think
> something similar is needed if you want to use this with PUBLISH. In
> practice this probably means documenting how EAP should use 'full' and
> 'partial' state in the context of etag.

That sounds very straight forward to me. However, specifying partial 
publishing falls out of scope for the PUBLISH specification, so I think 
we are talking about a presence publication extension that will have to 
be addressed separately in the future.

Cheers,
Aki

> 
> - Mikko
> 
> 
>>Cheers,
>>Aki
>>
>>
>>>/Hisham
>>>
>>>
>>>
>>>>While this doesn't spell out what a presence composer 
>>
>>policy should 
>>
>>>>be, it at least gives the composer more tools for deriving from an 
>>>>incoming publication the type of state change that occurred, and 
>>>>where exactly it occurred.
>>>>
>>>>Thoughts?
>>>>
>>>>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

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



From exim@www1.ietf.org  Fri Dec 19 11:31:40 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14966
	for <sip-archive@odin.ietf.org>; Fri, 19 Dec 2003 11:31:40 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXNWy-00084t-Jz
	for sip-archive@odin.ietf.org; Fri, 19 Dec 2003 11:31:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJGVC1l030994
	for sip-archive@odin.ietf.org; Fri, 19 Dec 2003 11:31:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXNWo-00082s-IL; Fri, 19 Dec 2003 11:31:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXNWi-000828-Lb
	for sip@optimus.ietf.org; Fri, 19 Dec 2003 11:30:56 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14915
	for <sip@ietf.org>; Fri, 19 Dec 2003 11:30:54 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXNWh-0000Bh-00
	for sip@ietf.org; Fri, 19 Dec 2003 11:30:55 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXNWg-0000Ba-00
	for sip@ietf.org; Fri, 19 Dec 2003 11:30:55 -0500
Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXNWg-0000Ao-00
	for sip@ietf.org; Fri, 19 Dec 2003 11:30:54 -0500
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hBJGUDd32472;
	Fri, 19 Dec 2003 10:30:13 -0600
From: Robert Sparks <rsparks@dynamicsoft.com>
To: sip-implementors@cs.columbia.edu
Cc: sip@ietf.org
In-Reply-To: <1070661467.911.30.camel@RjS.localdomain>
References: <1070661467.911.30.camel@RjS.localdomain>
Content-Type: text/plain
Message-Id: <1071851412.1380.43.camel@RjS.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Fri, 19 Dec 2003 10:30:13 -0600
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Sip] Re: SIPIT 14 Registration
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

If you are planning to attend SIPIT 14 and haven't registered,
please take a few moments to do so today. The deadlines for
registration are listed below - note in particular the deadline
of Jan 9 for securing a room at the event.

RjS


On Fri, 2003-12-05 at 15:57, Robert Sparks wrote:
> SIPIT 14 Registration is open.
> 
> The event will be held  9-February through 13-February 2004.
> 
> The last day to register is 16-January-2004
> (The last day to secure a room at the event is 9-January-2004)
> 
> If you plan to attend, but have not already registered, please do
> so soon.
> 
> Registration information is available at:
> http://www.etsi.org/plugtests/SIPIT14.htm	
> 
> 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 exim@www1.ietf.org  Sat Dec 20 15:14:43 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18341
	for <sip-archive@odin.ietf.org>; Sat, 20 Dec 2003 15:14:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXnUM-0007qr-0p
	for sip-archive@odin.ietf.org; Sat, 20 Dec 2003 15:14:14 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBKKEDwO030121
	for sip-archive@odin.ietf.org; Sat, 20 Dec 2003 15:14:13 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXnU9-0007og-Ai; Sat, 20 Dec 2003 15:14:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AXnU1-0007oR-5u
	for sip@optimus.ietf.org; Sat, 20 Dec 2003 15:13:53 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18230
	for <sip@ietf.org>; Sat, 20 Dec 2003 15:13:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXnTz-00058X-00
	for sip@ietf.org; Sat, 20 Dec 2003 15:13:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXnTz-00058P-00
	for sip@ietf.org; Sat, 20 Dec 2003 15:13:51 -0500
Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXnTy-00057s-00
	for sip@ietf.org; Sat, 20 Dec 2003 15:13:50 -0500
Received: from softarmor.com (c-24-1-178-197.client.comcast.net [24.1.178.197])
	(authenticated bits=0)
	by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hBKKHVtH005919
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <sip@ietf.org>; Sat, 20 Dec 2003 14:17:32 -0600
Message-ID: <3FE4AD5F.6080205@softarmor.com>
Date: Sat, 20 Dec 2003 14:13:19 -0600
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [Sip] test, please ignore
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


Somebody said they were getting bounces, so I'm checking.

--
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 exim@www1.ietf.org  Tue Dec 23 06:31:52 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16223
	for <sip-archive@odin.ietf.org>; Tue, 23 Dec 2003 06:31:52 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYkl4-000301-9v
	for sip-archive@odin.ietf.org; Tue, 23 Dec 2003 06:31:26 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNBVQD5011525
	for sip-archive@odin.ietf.org; Tue, 23 Dec 2003 06:31:26 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYkkh-0002xU-TW; Tue, 23 Dec 2003 06:31:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYkkY-0002wM-MH
	for sip@optimus.ietf.org; Tue, 23 Dec 2003 06:30:55 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16186
	for <sip@ietf.org>; Tue, 23 Dec 2003 06:30:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYkkU-0000y9-01
	for sip@ietf.org; Tue, 23 Dec 2003 06:30:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYkjF-0000xB-00
	for sip@ietf.org; Tue, 23 Dec 2003 06:29:33 -0500
Received: from tiere.net.avaya.com ([198.152.12.100])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYkjE-0000x8-00
	for sip@ietf.org; Tue, 23 Dec 2003 06:29:32 -0500
Received: from tiere.net.avaya.com (localhost [127.0.0.1])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBNBSpK4025915
	for <sip@ietf.org>; Tue, 23 Dec 2003 06:28:52 -0500 (EST)
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51])
	by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBNBSnK4025861
	for <sip@ietf.org>; Tue, 23 Dec 2003 06:28:50 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Dec 2003 13:29:31 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F04259955@is0004avexu1.global.avaya.com>
Thread-Topic: sip standard related query
Thread-Index: AcPJRCFRKxyG+Y14RLSapjchW17HLgAAy9pg
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Chirag Dhruv" <chirag@einfochips.com>, <sip@ietf.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] RE: sip standard related query
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Chirag,

RFC 2543 is not the latest standard for SIP. RFC 2543 was obsolete by =
RFC 3261 through RFC 3265. It is hard to establish whether 'there is no =
need to implement other standards' in your device without knowing what =
your device is. I would rather say that in most of the cases I know SIP =
is just one element of a solution, that according to the application =
includes the need to support other standards like RTP, SDP, etc.

Regards,

Dan



> -----Original Message-----
> From: Chirag Dhruv [mailto:chirag@einfochips.com]
> Sent: 23 December, 2003 1:12 PM
> To: sip@ietf.org; Romascanu, Dan (Dan)
> Subject: sip standard related query
>=20
>=20
> Hi
>=20
> I am new to SIP and in the process of feasibility study for=20
> SIP. I went=20
> through a lot of material on the web, and failed to=20
> understand if there=20
> is a common standard for SIP protocol or not. I understand=20
> that RFC2543=20
> is the latest starndard available till now, and if I implement that=20
> standard in my device, there is no need to implement other standards.
>=20
> Looking for a response.
>=20
> Thanks and Regards,
> Chirag.
>=20
>=20

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



From exim@www1.ietf.org  Tue Dec 23 07:43:45 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17951
	for <sip-archive@odin.ietf.org>; Tue, 23 Dec 2003 07:43:44 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYlsa-00057Q-2w
	for sip-archive@odin.ietf.org; Tue, 23 Dec 2003 07:43:16 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNChGpk019670
	for sip-archive@odin.ietf.org; Tue, 23 Dec 2003 07:43:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYlsL-00056L-Kd; Tue, 23 Dec 2003 07:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AYlrY-00055p-Et
	for sip@optimus.ietf.org; Tue, 23 Dec 2003 07:42:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17928
	for <sip@ietf.org>; Tue, 23 Dec 2003 07:42:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AYlrS-00034o-00
	for sip@ietf.org; Tue, 23 Dec 2003 07:42:06 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AYlpd-00036x-00
	for sip@ietf.org; Tue, 23 Dec 2003 07:40:14 -0500
Received: from [203.88.139.151] (helo=qmailserver)
	by ietf-mx with smtp (Exim 4.12)
	id 1AYlpb-000361-00
	for sip@ietf.org; Tue, 23 Dec 2003 07:40:12 -0500
Received: (qmail 27993 invoked from network); 23 Dec 2003 11:16:20 -0000
Received: from unknown (HELO einfochips.com) (192.168.9.170)
  by 0 with SMTP; 23 Dec 2003 11:16:20 -0000
Message-ID: <3FE83885.6070603@einfochips.com>
Date: Tue, 23 Dec 2003 18:13:49 +0530
From: Chirag Dhruv <chirag@einfochips.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: sip@ietf.org
Subject: Re: [Sip] RE: sip standard related query
References: <AAB4B3D3CF0F454F98272CBE187FDE2F04259955@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F04259955@is0004avexu1.global.avaya.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Thanks a lot for the prompt response.

I was also wondering if SIP is implemented in Hardware or software. It 
seems like it might be implemented using software.

Any hard IP is available or planned for the same?

Thanks and Regards,
Chirag.

Romascanu, Dan (Dan) wrote:

>Chirag,
>
>RFC 2543 is not the latest standard for SIP. RFC 2543 was obsolete by RFC 3261 through RFC 3265. It is hard to establish whether 'there is no need to implement other standards' in your device without knowing what your device is. I would rather say that in most of the cases I know SIP is just one element of a solution, that according to the application includes the need to support other standards like RTP, SDP, etc.
>
>Regards,
>
>Dan
>
>
>
>  
>
>>-----Original Message-----
>>From: Chirag Dhruv [mailto:chirag@einfochips.com]
>>Sent: 23 December, 2003 1:12 PM
>>To: sip@ietf.org; Romascanu, Dan (Dan)
>>Subject: sip standard related query
>>
>>
>>Hi
>>
>>I am new to SIP and in the process of feasibility study for 
>>SIP. I went 
>>through a lot of material on the web, and failed to 
>>understand if there 
>>is a common standard for SIP protocol or not. I understand 
>>that RFC2543 
>>is the latest starndard available till now, and if I implement that 
>>standard in my device, there is no need to implement other standards.
>>
>>Looking for a response.
>>
>>Thanks and Regards,
>>Chirag.
>>
>>
>>    
>>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP 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 exim@www1.ietf.org  Wed Dec 24 04:32:51 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02312
	for <sip-archive@odin.ietf.org>; Wed, 24 Dec 2003 04:32:51 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ5NL-00039v-OO
	for sip-archive@odin.ietf.org; Wed, 24 Dec 2003 04:32:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBO9WJVK012088
	for sip-archive@odin.ietf.org; Wed, 24 Dec 2003 04:32:19 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ5N4-000382-Rm; Wed, 24 Dec 2003 04:32:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ5Mt-00037Y-Jk
	for sip@optimus.ietf.org; Wed, 24 Dec 2003 04:31:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02309
	for <sip@ietf.org>; Wed, 24 Dec 2003 04:31:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZ5Mq-0000Ii-00
	for sip@ietf.org; Wed, 24 Dec 2003 04:31:48 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZ5L5-0000HI-00
	for sip@ietf.org; Wed, 24 Dec 2003 04:30:00 -0500
Received: from gw.softfront.co.jp ([202.232.222.2] helo=mail2.softfront.co.jp)
	by ietf-mx with smtp (Exim 4.12)
	id 1AZ5K0-0000ER-00
	for sip@ietf.org; Wed, 24 Dec 2003 04:28:52 -0500
Received: from wstar by mail2.softfront.co.jp id AA01588 ; 24 Dec 2003 18:28:13 +0900
Date: Wed, 24 Dec 2003 18:28:43 +0900
From: OKUMURA Shinji <shin@softfront.co.jp>
To: sip@ietf.org
Organization: SOFTFRONT
X-Mailer: Datula version 1.50.45 for Windows
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Message-Id: <200312240928.AA01588@mail2.softfront.co.jp>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Sip] PUBLISH-ing through a proxy
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

Hi folks: 

The only example (section 10) present in draft-ietf-sip-publish-01 
illustrates as: 

       PUA                     PA                    WATCHER 
      (EPA)                   (ESC) 
        |                       |                       | 
        |                       |                       | 
        | ---- M5: PUBLISH ---> |                       | 
        |                       |                       | 
        | <--- M6: 200 OK ----  |                       | 
        |                       |                       | 
        |                       |                       | 
 
where, 

   M5:  PUBLISH sip:presentity@example.com SIP/2.0 

Now, if we consider the existence of a proxy between PUA & PA as 
illustrated below, I'm afraid that M5 might be forwarded back to 
PUA (sip:presentity@example.com). 

       PUA                          proxy                    PA 
      (sip:presentity@example.com)    |                       | 
        | ---- M5: PUBLISH ---------> |                       | 
        |                             |                       | 
        | <--- M5': PUBLISH --------- |                       | 

Therefore, I believe that the appropriate Request-URI of M5 in 
this case should be 

sip:presence.example.com 
or
sip:presence_server@example.com 

It looks also reasonable if we consider that PUBLISH is analogous 
to REGISTER as mentioned in the main draft.

Am I right or missing something? 

Thanks in advance. 
_________________________________________________
OKUMURA Shinji        E-mail:shin@softfront.co.jp

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



From exim@www1.ietf.org  Wed Dec 24 09:07:39 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10715
	for <sip-archive@odin.ietf.org>; Wed, 24 Dec 2003 09:07:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ9fL-0004jK-8N
	for sip-archive@odin.ietf.org; Wed, 24 Dec 2003 09:07:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBOE7ACY018106
	for sip-archive@odin.ietf.org; Wed, 24 Dec 2003 09:07:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ9fB-0004eg-UD; Wed, 24 Dec 2003 09:07:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZ9eh-0004e2-IG
	for sip@optimus.ietf.org; Wed, 24 Dec 2003 09:06:31 -0500
Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10709
	for <sip@odin.ietf.org>; Wed, 24 Dec 2003 09:06:29 -0500 (EST)
Received: from apache by asgard.ietf.org with local (Exim 4.14)
	id 1AZ9e0-00044Z-4v; Wed, 24 Dec 2003 09:05:48 -0500
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
Cc: Internet Architecture Board <iab@iab.org>,
        RFC Editor <rfc-editor@rfc-editor.org>, <sip@ietf.org>
Message-Id: <E1AZ9e0-00044Z-4v@asgard.ietf.org>
Date: Wed, 24 Dec 2003 09:05:48 -0500
Subject: [Sip] Protocol Action: 'Caller Preferences for the Session
 Initiation Protocol (SIP)' to Proposed Standard
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

The IESG has approved the following document:

- 'Caller Preferences for the Session Initiation Protocol (SIP) '
   <draft-ietf-sip-callerprefs-10.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

Technical Summary
 
  This document describes a set of extensions to the Session Initiation
   Protocol (SIP) which allow a caller to express preferences about
   request handling in servers. These preferences include the ability to
   select which Uniform Resource Identifiers (URI) a request gets routed
   to, and to specify certain request handling directives in proxies and
   redirect servers. It does so by defining three new request header
   fields, Accept-Contact, Reject-Contact, and Request-Disposition,
   which specify the caller's preferences.

Working Group Summary

  The working group participated in very active review, and then reached
   a point of strong support of advancement.   There was a mid-course review
   started by the Applications Area Director for SIMPLE of the time, Patrik 
   Faltstrom, and continued by his successor, Ted Hardie.  This resulted in
   many clarifying changes in design, and the split of functions (proposed
   by Ted) into caller prefs in this document, and callee caps, 
   also in review. 

Protocol Quality

   There are prototypes of this specification (in earlier versions).  The 
   reviewing for the IESG was done by Allison Mankin and Ted Hardie.

RFC Editor Notes

Section 5.2

Old:

   As an example, the following Accept-Contact header field expresses a 
   desire to route a call to a mobile device:

New:

  As an example, the following Accept-Contact header field expresses a
  desire to route a call to a mobile device, using feature
  parameters taken from [3]:


Section 8

Add to the reference to RFC 2506  [13], and add to the Informative
References

[13] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
         Registration Procedure", BCP 31, RFC 2506, March 1999.


Section 10

Old:

           parallel-directive / queue-directive)

New:

           parallel-directive / queue-directive


Old:

          ;;feature param from RFC XXXX

New:

          ;;feature param from RFC XXXX (substitute for XXX 
          ;;the RFC number of draft-ietf-sip-callee-caps)

Section 11  Security Considerations

Old:  

The presence of caller preferences in a request has an effect on the
ways in which the request is handled at a server. As a result, it is
especially important that requests with caller preferences be
integrity-protected.

New:

The presence of caller preferences in a request has an effect on the
ways in which the request is handled at a server. As a result, requests
with caller preferences SHOULD be integrity-protected with the sips
mechanism specified in RFC 3261, Section 26.


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



From exim@www1.ietf.org  Wed Dec 24 16:32:46 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24286
	for <sip-archive@odin.ietf.org>; Wed, 24 Dec 2003 16:32:46 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZGc6-0003hr-I6
	for sip-archive@odin.ietf.org; Wed, 24 Dec 2003 16:32:18 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBOLWIbW014243
	for sip-archive@odin.ietf.org; Wed, 24 Dec 2003 16:32:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZGbq-0003gN-A2; Wed, 24 Dec 2003 16:32:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AZGbo-0003g8-GF
	for sip@optimus.ietf.org; Wed, 24 Dec 2003 16:32:00 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24229
	for <sip@ietf.org>; Wed, 24 Dec 2003 16:31:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZGbm-0001nd-00
	for sip@ietf.org; Wed, 24 Dec 2003 16:31:58 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AZGZt-0001kf-00
	for sip@ietf.org; Wed, 24 Dec 2003 16:30:01 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AZGY5-0001ew-00
	for sip@ietf.org; Wed, 24 Dec 2003 16:28:09 -0500
Received: from dynamicsoft.com ([63.113.46.15])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBOLRhmR006002;
	Wed, 24 Dec 2003 16:27:44 -0500 (EST)
Message-ID: <3FEA04CA.2060707@dynamicsoft.com>
Date: Wed, 24 Dec 2003 16:27:38 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Anders Kristensen <akristensen@dynamicsoft.com>
CC: SIP <sip@ietf.org>
Subject: Re: [Sip] 3pcc draft: SDP seq-no issue
References: <3F902081.9050206@dynamicsoft.com>
In-Reply-To: <3F902081.9050206@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL,DOMAIN_BODY autolearn=no 
	version=2.60
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Another old mail - apologies for the very late response.

Anders Kristensen wrote:

> In the example in section 10.2 of the 3pcc draft, 
> draft-ietf-sipping-3pcc-04.txt, the controller disconnects the callee 
> (called party of b2bua or 3pcc call) by sending a re-INVITE with a 
> connection address in the .invalid domain. Later on the called party is 
> reconnected with the caller by using one of the 3pcc flows.
> 
> One problem with this, not mentioned in the draft, is that the 
> controller has to bump up the o= SDP version number when sending the 
> disconnect re-INVITE. Since the caller may not have to change its SDP in 
> offer (5) and answer (16) it may not update its SDP version number, 
> meaning the controller will have to rewrite it in (17) answer3' sent to 
> the callee (and keep on doing it for any subsequent re-INVITEs).
> 
> It seems that SDP version numbers could be an issue whenever any of the 
> flows is used after initial call establishment?

Yes. I've added text to the spec which discusses this:

<t>From here, new parties can be added, removed, transferred, and so on,
as the controller sees fit. In many cases, the controller will be
required to modify the SDP exchanged between the participants in order
to affect these changes. In particular, the version number in the SDP
will need to be changed by the controller in certain cases. If the
controller should issue an SDP offer on its own (for example, to place
a call on hold), it will need to increment the version number in the
SDP offer. The other participant in the call will not know that the
controller has done this, and any subsequent offer it generates will
have the wrong version number as far as its peer is concerned. As a
result, the controller will be required to modify the version number
in SDP messages to match what the recipient is expecting.
</t>


> 
> BTW, RFC 3264 has the following slightly curious formulation:
> 
>    When issuing an offer that modifies the session,
>    the "o=" line of the new SDP MUST be identical to that in the
>    previous SDP, except that the version in the origin field MUST
>    increment by one from the previous SDP.  If the version in the origin
>    line does not increment, the SDP MUST be identical to the SDP with
>    that version number.  The answerer MUST be prepared to receive an
>    offer that contains SDP with a version that has not changed; this is
>    effectively a no-op.
> 
> Is "MUST increment by one" supposed to be interpreted to mean "by at 
> least one" or is this really intended to strengthen the requirements of 
> RFC 2327?

It is as written - increment by one, which strengthens the requirement 
compared to rfc2327.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Mon Dec 29 04:35:54 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21926
	for <sip-archive@odin.ietf.org>; Mon, 29 Dec 2003 04:35:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aato5-0003qd-Uo
	for sip-archive@odin.ietf.org; Mon, 29 Dec 2003 04:35:26 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBT9ZPt7014792
	for sip-archive@odin.ietf.org; Mon, 29 Dec 2003 04:35:25 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aatnm-0003pS-1P; Mon, 29 Dec 2003 04:35:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aatn0-0003oD-CQ
	for sip@optimus.ietf.org; Mon, 29 Dec 2003 04:34:18 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21914
	for <sip@ietf.org>; Mon, 29 Dec 2003 04:34:15 -0500 (EST)
From: aki.niemi@nokia.com
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aatmx-0007GI-00
	for sip@ietf.org; Mon, 29 Dec 2003 04:34:15 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AatlW-0007Ao-00
	for sip@ietf.org; Mon, 29 Dec 2003 04:32:47 -0500
Received: from mgw-x4.nokia.com ([131.228.20.27])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AatkV-000706-00
	for sip@ietf.org; Mon, 29 Dec 2003 04:31:43 -0500
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBT9ViU17494
	for <sip@ietf.org>; Mon, 29 Dec 2003 11:31:44 +0200 (EET)
Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T66ce29b2bfac158f24078@esvir04nok.ntc.nokia.com>;
 Mon, 29 Dec 2003 11:31:43 +0200
Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747);
	 Mon, 29 Dec 2003 11:31:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sip] PUBLISH-ing through a proxy
Date: Mon, 29 Dec 2003 11:31:08 +0200
Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D59311@esebe013.ntc.nokia.com>
Thread-Topic: [Sip] PUBLISH-ing through a proxy
Thread-Index: AcPKAOIRaxZhNe+ySUqbTnxNFOkZVgD6mDpA
To: <shin@softfront.co.jp>, <sip@ietf.org>
X-OriginalArrivalTime: 29 Dec 2003 09:31:42.0087 (UTC) FILETIME=[9157D970:01C3CDEE]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no 
	version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

Hi,

Inline.=20

 > -----Original Message-----
 > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext
 > OKUMURA Shinji
 > Sent: 24 December, 2003 11:29
 > To: sip@ietf.org
 > Subject: [Sip] PUBLISH-ing through a proxy
 >=20
 >=20
 > Hi folks:=20
 >=20
 > The only example (section 10) present in draft-ietf-sip-publish-01=20
 > illustrates as:=20
 >=20
 >        PUA                     PA                    WATCHER=20
 >       (EPA)                   (ESC)=20
 >         |                       |                       |=20
 >         |                       |                       |=20
 >         | ---- M5: PUBLISH ---> |                       |=20
 >         |                       |                       |=20
 >         | <--- M6: 200 OK ----  |                       |=20
 >         |                       |                       |=20
 >         |                       |                       |=20
 > =20
 > where,=20
 >=20
 >    M5:  PUBLISH sip:presentity@example.com SIP/2.0=20
 >=20
 > Now, if we consider the existence of a proxy between PUA & PA as=20
 > illustrated below, I'm afraid that M5 might be forwarded back to=20
 > PUA (sip:presentity@example.com).=20
 >=20
 >        PUA                          proxy                    PA=20
 >       (sip:presentity@example.com)    |                       |=20
 >         | ---- M5: PUBLISH ---------> |                       |=20
 >         |                             |                       |=20
 >         | <--- M5': PUBLISH --------- |                       |=20
 >=20
 > Therefore, I believe that the appropriate Request-URI of M5 in=20
 > this case should be=20
 >=20
 > sip:presence.example.com=20
 > or
 > sip:presence_server@example.com=20
 >=20
 > It looks also reasonable if we consider that PUBLISH is analogous=20
 > to REGISTER as mentioned in the main draft.

Actually, there is a bug in sip-publish-01, in that it is still not =
crystal clear about what should go into the Request-URI, and what should =
go into the To, and how they are used.

As far as addressing a request is concerned, PUBLISH is analogous to a =
SUBSCRIBE. The Request-URI indicates the resource that the PUBLISH is =
targeting. The scenario you describe above can also happen for =
SUBSCRIBE, if there is no PA configured for the resource in the =
Request-URI. In fact, when a PA/ESC is located at the UA, this is =
exactly what should happen, i.e., all PUBLISH and SUBSCRIBE requests are =
serviced by that UA.

 > Am I right or missing something?=20

I put some additional text into "sip-publish-02" that will hopefully be =
able to clarify this issue, and the relationship between PUBLISH, =
REGISTER and SUBSCRIBE.

Thanks,
Aki

 > Thanks in advance.=20
 > _________________________________________________
 > OKUMURA Shinji        E-mail:shin@softfront.co.jp
 >=20
 > _______________________________________________
 > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
 > This list is for NEW development of the core SIP Protocol
 > Use sip-implementors@cs.columbia.edu for questions on current sip
 > Use sipping@ietf.org for new developments on the application of sip
 >=20

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



From exim@www1.ietf.org  Mon Dec 29 10:17:03 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01302
	for <sip-archive@odin.ietf.org>; Mon, 29 Dec 2003 10:17:02 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaz8E-0005HQ-Rm
	for sip-archive@odin.ietf.org; Mon, 29 Dec 2003 10:16:35 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTFGYVe020237
	for sip-archive@odin.ietf.org; Mon, 29 Dec 2003 10:16:34 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaz7i-0005Eq-Vc; Mon, 29 Dec 2003 10:16:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Aaz7d-0005E6-0K
	for sip@optimus.ietf.org; Mon, 29 Dec 2003 10:15:57 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01164
	for <sip@ietf.org>; Mon, 29 Dec 2003 10:15:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aaz7a-0000zU-00
	for sip@ietf.org; Mon, 29 Dec 2003 10:15:54 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Aaz5g-0000w8-00
	for sip@ietf.org; Mon, 29 Dec 2003 10:13:56 -0500
Received: from [168.226.49.107] (helo=mail3.telefonica.com.ar)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Aaz3p-0000re-00
	for sip@ietf.org; Mon, 29 Dec 2003 10:12:02 -0500
Received: from mailhub.telefonica.com.ar ([10.249.7.11]) by mail3 with InterScan Messaging Security Suite; Mon, 29 Dec 2003 12:06:02 -0300
Received: by mailhub.telefonica.com.ar with Internet Mail Service (5.5.2657.72)
	id <YSHDZL5L>; Mon, 29 Dec 2003 12:04:29 -0300
Message-ID: <C7F15EC9E01FD211B88200805F1565EC1829B82B@mstelefonica5.telefonica.com.ar>
From: "Larrauri Adrian Oscar (Tecnologia)" <larraura@TELEFONICA.COM.AR>
To: "'sip@ietf.org'" <sip@ietf.org>
Date: Mon, 29 Dec 2003 12:04:26 -0300
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,SUBJ_ALL_CAPS,
	X_PRIORITY_HIGH autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Subject: [Sip] SEQUENTIAL FORKING
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

I need to know,  =BF where can I find examples ( call flows) about "
sequential forking " ?

Bye=20

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



From exim@www1.ietf.org  Mon Dec 29 13:31:50 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07411
	for <sip-archive@odin.ietf.org>; Mon, 29 Dec 2003 13:31:50 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ab2Ak-0003hd-6w
	for sip-archive@odin.ietf.org; Mon, 29 Dec 2003 13:31:22 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBTIVMaa014227
	for sip-archive@odin.ietf.org; Mon, 29 Dec 2003 13:31:22 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ab2AR-0003gY-Si; Mon, 29 Dec 2003 13:31:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Ab29c-0003em-Ou
	for sip@optimus.ietf.org; Mon, 29 Dec 2003 13:30:12 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07390
	for <sip@ietf.org>; Mon, 29 Dec 2003 13:30:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ab29a-0007Mx-00
	for sip@ietf.org; Mon, 29 Dec 2003 13:30:10 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Ab27j-0007Iq-00
	for sip@ietf.org; Mon, 29 Dec 2003 13:28:16 -0500
Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Ab26R-0007F2-00
	for sip@ietf.org; Mon, 29 Dec 2003 13:26:56 -0500
Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57])
	by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBTIQLc01098
	for <sip@ietf.org>; Mon, 29 Dec 2003 12:26:21 -0600 (CST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72)
	id <Y9ZVM75L>; Mon, 29 Dec 2003 18:26:17 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF83@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'sip@ietf.org'" <sip@ietf.org>
Cc: "'jdrosen@dynamicsoft.org'" <jdrosen@dynamicsoft.org.cnri.reston.va.us>,
        "'schulzrinne@cs.columbia.edu'" <schulzrinne@cs.columbia.edu>,
        "'pkzivat@cisco.com'" <pkzivat@cisco.com>
Date: Mon, 29 Dec 2003 18:26:10 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [Sip] Comments on draft-ietf-sip-callee-caps-01
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

I have the following comments and questions on the above draft:

1)	Given an indication of support of a specific feature, is there a requirement to indicate all other features supported that can be indicated using the protocol. I currently can find no words to indicate this one way or another. My preference would be to allow support only of those feature tags that an implementation considers "useful" for its implementation, but I would be concerned if the implementor of a peer entity took the opposite approach and insisted that my implementation was non-conformant for this reason. As one example, an "isfocus" is probably also an "automata". Is there a need to indicate both?

2)	I note that this extension uses the same option-tag as the callerprefs extension, i.e. "pref". Apart from using the same option-tag, I see no dependency between the two extensions, and it would appear completely valid for an implementation to support one extension and not the other. I would therefore have expected two completely different option-tags, one for each extension. Is there a reason for the option-tag reuse, apart from the history that these two extensions were originally one extension.

3)	Section 10.1 defines a number of feature tags relating to the support of media types. The text currently specifies that the use of these tags indicates "the device supports xxx as a media type". Surely in each case it would be more complete to state that "the device supports xxx as a media type, and the selection of that media type using SIP and SDP", assuming that that additional constraint applies.

4)	Section 10.1.5 mentions floor control protocol as an example. Would it not be sensible to avoid using floor control protocols as an example until XCON have decided what protocol the floor control protocol is, and how its use is negotiated. While I guess this could be any floor control protocol, SIP people will automatically think XCON for conferences.

5)	Section 10.2.4. Mobility feature. In the past we have had discussions about what this meant and whether it was useful. I thought in general the conclusion was that it wasn't particularly useful. It is certainly not useful if I don't understand what is meant by mobility. For example a 3GPP IMS user would be using a handset that would normally be regarded as mobile. However the mobility is supported entirely by the underlying layers, and SIP sees no mobility. The IP address and all other things remain static for the duration of a registration, even if the handset moves (I note that one of Gonzalo's drafts talks about session mobility only in the context of changing IP addresses). If I put my conference server on board an ocean liner, is it mobile or not? So if we keep this feature, can we have some more words to indicate what is a mobile UA, and what is a fixed one.

6)	Section 10.2.2. Class. I wonder if there are sufficient values here. Will this go the way of the top level domain names, and we will need an class=organisation for those phones that are neither business or personal.

regards

Keith 

Keith Drage
Lucent Technologies
drage@lucent.com
tel: +44 1793 776249

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



From exim@www1.ietf.org  Tue Dec 30 12:12:39 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29093
	for <sip-archive@odin.ietf.org>; Tue, 30 Dec 2003 12:12:39 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbNPf-0004P7-JB
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 12:12:12 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBUHCBQC016925
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 12:12:11 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbNOa-0004Mi-2w; Tue, 30 Dec 2003 12:11:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbNNt-0004KS-2D
	for sip@optimus.ietf.org; Tue, 30 Dec 2003 12:10:21 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28955
	for <sip@ietf.org>; Tue, 30 Dec 2003 12:10:18 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbNNr-0005eI-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:10:19 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbNLy-0005Xu-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:08:23 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbNKM-0005Sg-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:06:42 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 30 Dec 2003 09:12:18 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBUH69VM021484;
	Tue, 30 Dec 2003 09:06:10 -0800 (PST)
Received: from [192.168.0.4] (sjc-vpn3-639.cisco.com [10.21.66.127])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ALB62853;
	Tue, 30 Dec 2003 09:06:08 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 30 Dec 2003 09:06:09 -0800
Subject: Re: [Sip] Encryption in SIP
From: Cullen Jennings <fluffy@cisco.com>
To: Samir Chatterjee <samir.chatterjee@cgu.edu>,
        "'Gokul Krishnan'" <gktvm2@yahoo.com>, <sip@ietf.org>
Message-ID: <BC16F081.2ACE9%fluffy@cisco.com>
In-Reply-To: <9C6FE1166FC14444811E7AB3B1B6D7E5A35503@clarepost.cgu.edu>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3155619969_5945236"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=1.6 required=5.0 tests=BIZ_TLD,HTML_40_50,
	HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONT_BIG,HTML_MESSAGE 
	autolearn=no version=2.60
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>

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

--B_3155619969_5945236
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit


There are a few large companies that are implementing SMIME in SIP and
probably some other companies I am unaware of but it is certainly not
common. We have been doing some testing at the sip interop events. The
testing has been more around signed certs than self singed but I (and
others) have been playing with both.

Cullen


On 12/8/03 2:26 PM, "Samir Chatterjee" <samir.chatterjee@cgu.edu> wrote:

> Kind of curious to know if there is any commercial SIP implementation that
> does S/MIME ETE encryption of signaling as well as media encryption? Since
> these require digital certificates, are they suffering from similar trust
> issues of CAs? Are there any self-signed certs being used?
> Samir
>  
> 
> Dr. Samir  Chatterjee
> School of Information Science
> Claremont Graduate University
> 130 East 9th Street
> Claremont, CA 91711
> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: Monday,  December 08, 2003 12:03 PM
> To: 'Gokul Krishnan'; sip@ietf.org
> Subject: RE: [Sip] Encryption in SIP
>  
> 
>  
> 
> See RFC3261 Section 23, especially 23.4.1 and 23.4.3.
> 
>  
> 
> Jon Peterson
> 
> NeuStar, Inc.
>> -----Original Message-----
>> From: Gokul Krishnan [mailto:gktvm2@yahoo.com]
>> Sent: Saturday, December 06, 2003 3:08 AM
>> To: sip@ietf.org
>> Subject: [Sip] Encryption in SIP
>> 
>> Hi All,
>> 
>>  
>> 
>> A query on Encryption in SIP.
>> 
>>  
>> 
>> How is end-to-end encryption achieved in SIP? RFC2543 had headers -
>> Encryption and Response-Key. But in RFC3261 I could only see the mentioning
>> about hop-by-hop encryption using TL/IPSec. Please point to me to the correct
>> portion of RFC in case I am missing something.
>> 
>>  
>> 
>> Thanks
>> 
>> Gokul 
>> 
>> 
>> Do you Yahoo!?
>> New Yahoo! Photos - easier uploading and sharing
>> <http://pa.yahoo.com/*http:/us.rd.yahoo.com/evt=21260/*http:/photos.yahoo.com
>> > 
> 



--B_3155619969_5945236
Content-type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Sip] Encryption in SIP</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><BR>
There are a few large companies that are implementing SMIME in SIP and prob=
ably some other companies I am unaware of but it is certainly not common. We=
 have been doing some testing at the sip interop events. The testing has bee=
n more around signed certs than self singed but I (and others) have been pla=
ying with both. <BR>
<BR>
Cullen<BR>
<BR>
<BR>
On 12/8/03 2:26 PM, &quot;Samir Chatterjee&quot; &lt;samir.chatterjee@cgu.e=
du&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:14.0px'><FONT COLOR=3D"#0000=
80"><FONT FACE=3D"Arial">Kind of curious to know if there is any commercial SI=
P implementation that does S/MIME ETE encryption of signaling as well as med=
ia encryption? Since these require digital certificates, are they suffering =
from similar trust issues of CAs? Are there any self-signed certs being used=
?<BR>
Samir<BR>
&nbsp;<BR>
</FONT></FONT><FONT FACE=3D"Verdana"><BR>
</FONT><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Dr. Samir &nbsp;Chatterjee<=
BR>
School of Information Science<BR>
Claremont Graduate University<BR>
130 East 9th Street<BR>
Claremont, CA 91711<BR>
</FONT></FONT><FONT FACE=3D"Tahoma">-----Original Message-----<BR>
<B>From:</B> Peterson, Jon [<a href=3D"mailto:jon.peterson@neustar.biz]">mail=
to:jon.peterson@neustar.biz]</a> <BR>
<B>Sent:</B> Monday, &nbsp;December 08, 2003 12:03 PM<BR>
<B>To:</B> 'Gokul Krishnan'; sip@ietf.org<BR>
<B>Subject:</B> RE: [Sip] Encryption in SIP<BR>
</FONT></SPAN><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font=
-size:18.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><B=
R>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font=
-size:18.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><B=
R>
</SPAN></FONT><SPAN STYLE=3D'font-size:14.0px'><FONT COLOR=3D"#0000FF"><FONT FA=
CE=3D"Arial">See RFC3261 Section 23, especially 23.4.1 and 23.4.3.<BR>
</FONT></FONT><FONT FACE=3D"Verdana"><BR>
</FONT></SPAN><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font=
-size:18.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><B=
R>
</SPAN></FONT><SPAN STYLE=3D'font-size:14.0px'><FONT COLOR=3D"#0000FF"><FONT FA=
CE=3D"Arial">Jon Peterson<BR>
</FONT></FONT><FONT FACE=3D"Verdana"><BR>
</FONT><FONT COLOR=3D"#0000FF"><FONT FACE=3D"Arial">NeuStar, Inc.<BR>
</FONT></FONT></SPAN><BLOCKQUOTE><SPAN STYLE=3D'font-size:14.0px'><FONT FACE=3D=
"Tahoma">-----Original Message-----<BR>
<B>From:</B> Gokul Krishnan [<a href=3D"mailto:gktvm2@yahoo.com]">mailto:gktv=
m2@yahoo.com]</a><BR>
<B>Sent:</B> Saturday, December 06, 2003 3:08 AM<BR>
<B>To:</B> sip@ietf.org<BR>
<B>Subject:</B> [Sip] Encryption in SIP<BR>
</FONT><FONT FACE=3D"Verdana"><BR>
</FONT></SPAN><FONT FACE=3D"Verdana"><FONT COLOR=3D"#800000"><FONT SIZE=3D"4"><SP=
AN STYLE=3D'font-size:18.0px'>Hi All,<BR>
</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:14.0px'><BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font=
-size:18.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><B=
R>
</SPAN><FONT COLOR=3D"#800000"><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:18.0px'>=
A query on Encryption in SIP.<BR>
</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:14.0px'><BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font=
-size:18.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><B=
R>
</SPAN><FONT COLOR=3D"#800000"><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:18.0px'>=
How is <B>end-to-end encryption</B> achieved in SIP? RFC2543 had headers - E=
ncryption and Response-Key. But in RFC3261 I could only see the mentioning a=
bout hop-by-hop encryption using TL/IPSec. Please point to me to the correct=
 portion of RFC in case I am missing something.<BR>
</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:14.0px'><BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font=
-size:18.0px'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><B=
R>
</SPAN><FONT COLOR=3D"#800000"><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:18.0px'>=
Thanks<BR>
</SPAN></FONT></FONT><SPAN STYLE=3D'font-size:14.0px'><BR>
</SPAN><FONT COLOR=3D"#800000"><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:18.0px'>=
Gokul
</SPAN></FONT></FONT></FONT>
<P ALIGN=3DCENTER>
<FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:18.0px'><FONT FACE=3D"Times New Roman">=
<HR ALIGN=3DCENTER SIZE=3D"1" WIDTH=3D"100%"></FONT></SPAN></FONT>
<P>
<FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0px'><BR>
</SPAN></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font=
-size:18.0px'>Do you Yahoo!?<BR>
New Yahoo! Photos - easier uploading and sharing <a href=3D"http://pa.yahoo.c=
om/*http:/us.rd.yahoo.com/evt=3D21260/*http:/photos.yahoo.com">&lt;http://pa.y=
ahoo.com/*http:/us.rd.yahoo.com/evt=3D21260/*http:/photos.yahoo.com&gt;</a> <B=
R>
</SPAN></FONT></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-si=
ze:14.0px'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Verdana"><SPAN STYLE=3D'font-size:14.0=
px'><BR>
</SPAN></FONT>
</BODY>
</HTML>


--B_3155619969_5945236--


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



From exim@www1.ietf.org  Tue Dec 30 12:19:38 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29548
	for <sip-archive@odin.ietf.org>; Tue, 30 Dec 2003 12:19:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbNWQ-0004n8-Qn
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 12:19:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBUHJAYE018358
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 12:19:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbNWI-0004ki-9x; Tue, 30 Dec 2003 12:19:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbNW0-0004jg-G0
	for sip@optimus.ietf.org; Tue, 30 Dec 2003 12:18:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29424
	for <sip@ietf.org>; Tue, 30 Dec 2003 12:18:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbNVz-0006Ek-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:18:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbNUQ-00065Y-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:17:06 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbNSV-0005tf-01
	for sip@ietf.org; Tue, 30 Dec 2003 12:15:07 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 30 Dec 2003 09:21:13 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBUHF3VM002871;
	Tue, 30 Dec 2003 09:15:04 -0800 (PST)
Received: from [192.168.0.4] (sjc-vpn3-639.cisco.com [10.21.66.127])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ALB63328;
	Tue, 30 Dec 2003 09:15:01 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 30 Dec 2003 09:15:01 -0800
Subject: TCP Close ( Was Re: AW: [Sip] Updated gruu mechanism spec
From: Cullen Jennings <fluffy@cisco.com>
To: Christian Stredicke <stredicke@snom.de>,
        "'Chris Boulton'" <cboulton@ubiquity.net>
CC: <sip@ietf.org>
Message-ID: <BC16F295.2ACF1%fluffy@cisco.com>
In-Reply-To: <008301c3bd6d$969296a0$60fd340a@sip>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable


Agree this has nothing to do with GRUU ...

I don't think I agree that closing the TCP connections frequently (like
after every transaction) lowers the load on the server. My experiments
indicate it makes it worse. I have been recommending that phones, once they
open an TCP connection, leave it open as long as they can but be prepared
for the proxy to close it if the proxy runs out of resources.

Cullen


On 12/8/03 1:28 AM, "Christian Stredicke" <stredicke@snom.de> wrote:

> Hi Chris,
>=20
> well usually it is a good idea for the UAC to close the TCP connection
> in order to keep the load on the server low. But in the specific case of
> obtaining a GRUU (behind NAT) this is not a good practice; therefore I
> think it fits well into the GRUU draft.
>=20
> Christian
>=20
>> -----Urspr=FCngliche Nachricht-----
>> Von: Chris Boulton [mailto:cboulton@ubiquity.net]
>> Gesendet: Montag, 8. Dezember 2003 17:16
>> An: Christian Stredicke; Jonathan Rosenberg
>> Cc: sip@ietf.org
>> Betreff: RE: [Sip] Updated gruu mechanism spec
>>=20
>> Christian,
>> I agree BUT isn't this a more generalized recommendation for
> UA's
>> using TCP.  Maybe this type of information would be better suited in a
>> generic TCP usage doc.
>>=20
>> Chris.
>>


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



From exim@www1.ietf.org  Tue Dec 30 12:51:38 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00973
	for <sip-archive@odin.ietf.org>; Tue, 30 Dec 2003 12:51:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbO1O-0006LF-Q6
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 12:51:11 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBUHpAak024376
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 12:51:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbO1G-0006KG-Um; Tue, 30 Dec 2003 12:51:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbO0y-0006JI-Pe
	for sip@optimus.ietf.org; Tue, 30 Dec 2003 12:50:45 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00935
	for <sip@ietf.org>; Tue, 30 Dec 2003 12:50:41 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbO0x-0007l8-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:50:43 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbNz3-0007fV-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:48:46 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbNyC-0007aF-00
	for sip@ietf.org; Tue, 30 Dec 2003 12:47:52 -0500
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 30 Dec 2003 09:53:28 +0000
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBUHlJVM009431;
	Tue, 30 Dec 2003 09:47:19 -0800 (PST)
Received: from [192.168.0.4] (sjc-vpn3-639.cisco.com [10.21.66.127])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ALB65155;
	Tue, 30 Dec 2003 09:47:17 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 30 Dec 2003 09:47:17 -0800
Subject: Re: [Sip] TCP FIN and SIP crossing
From: Cullen Jennings <fluffy@cisco.com>
To: Yosuke ITOH <itoh.yosuke@lab.ntt.co.jp>, <sip@ietf.org>
CC: <fukuda.yoshimi@lab.ntt.co.jp>, AkiraOno <ono.akira@lab.ntt.co.jp>,
        Vijay Gurbani <vkg@lucent.com>
Message-ID: <BC16FA25.2AD10%fluffy@cisco.com>
In-Reply-To: <3FD96CE8.8090309@lab.ntt.co.jp>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


I think this is an important issue to figure out - I don't know the answer.

This case can happen anywhere, it just that is is very likely to happen
every time with a REGISTAR that closes after ever transaction and challenges
for credentials. 

This problem is further complicated by the interaction with DNS. If the
client opens a new TCP connection to send the REGISTER with the credentials,
it may not even go to the same proxy and may result in another 401.

Some clients may interpret the closing of the TCP connection as 408 like
response on all the transactions that are currently on it. (See RFC 3261
Section 8.1.3.1). The paragraph on the top of pate 141 of 3261 might provide
some guidance on this but was more for outstanding transactions than a new
one getting created and crossing the FIN. We removed the TCP close = CANCEL
semantics so, I think the right thing for the REGISTRAR to do in this case
is to open a new TCP connection back to the client and send the 200 over
than. I don't know if the client should interpret the TCP close as an error
and send a 408 to the TU? Comments from others?

Clearly if the REGISTAR did not rapidly close the TCP connection that it had
just sent the digest challenge on, this would not happen as often. However,
that leaves a fairly interesting DOS problem. An unauthenticated client is
allowed to hold open a TCP socket which is a fairly limited resource on most
proxies. Hopefully the TCP best practices work will address this issue.

Cullen
 


On 12/11/03 11:23 PM, "Yosuke ITOH" <itoh.yosuke@lab.ntt.co.jp> wrote:

> Hi,
> 
> I have a question of TCP FIN and SIP crossing on wire.
> The following sequence actually happened during some of our tests.
> 
> client                   REGISTRAR
> 1 |----------SYN---------->|
> 2 |<-------SYN/ACK---------|
> 3 |----------ACK---------->|
> 4 |--------REGISTER------->|
> 5 |<---------401-----------|
> 6 |-REGISTER->   <-FIN/ACK-|
> 7 |<-FIN/ACK-   -REGISTER->|
> 8 |----------ACK---------->|
> 9 |<-------FIN/ACK---------|
> 10|<---------ACK-----------|
> 
> In this sequence, the REGISTRAR cannot send a "200 OK" because the TCP
> connection has already been closed.
> 
> Generally, clients are not aware of the state of the TCP connection (open
> or closed).
> 
> In this situation, a client cannot know that the connection was closed
> because the TCP connection was closed normally, without any errors.
> 
> One solution is that REGISTRAR sends back a "200 OK" after opening a
> new TCP connection.
> 
> I would like to know if there is a better way to solve this problem.
> 
> Thanks,
> 
> Yosuke Itoh


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



From exim@www1.ietf.org  Tue Dec 30 13:31:48 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02420
	for <sip-archive@odin.ietf.org>; Tue, 30 Dec 2003 13:31:48 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbOeH-0008Je-TV
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 13:31:21 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBUIVL4w031965
	for sip-archive@odin.ietf.org; Tue, 30 Dec 2003 13:31:21 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbOdz-0008IY-IC; Tue, 30 Dec 2003 13:31:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbOdW-0008Gb-IX
	for sip@optimus.ietf.org; Tue, 30 Dec 2003 13:30:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02387
	for <sip@ietf.org>; Tue, 30 Dec 2003 13:30:30 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbOdU-0001bo-00
	for sip@ietf.org; Tue, 30 Dec 2003 13:30:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbObm-0001Yz-00
	for sip@ietf.org; Tue, 30 Dec 2003 13:28:47 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbOa4-0001UM-00
	for sip@ietf.org; Tue, 30 Dec 2003 13:27:00 -0500
Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBUIQSVM022242;
	Tue, 30 Dec 2003 10:26:28 -0800 (PST)
Received: from [192.168.0.4] (sjc-vpn3-639.cisco.com [10.21.66.127])
	by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id ALB67758;
	Tue, 30 Dec 2003 10:26:26 -0800 (PST)
User-Agent: Microsoft-Entourage/10.1.4.030702.0
Date: Tue, 30 Dec 2003 10:26:26 -0800
Subject: Re: [Sip] Updated gruu mechanism spec
From: Cullen Jennings <fluffy@cisco.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>, <sip@ietf.org>
Message-ID: <BC170352.2AD3B%fluffy@cisco.com>
In-Reply-To: <3FD104AF.2030505@dynamicsoft.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit


I feel this should be adopted as a WG time with new milestone.

One curiosity question about the GRID parameter - it says that "MUST NOT
exceed 128 characters". I was wondering why this was added. I'm not really
against it but it struck me as inconsistent with all the the other things in
SIP which have no limit. 128 is also fairly low for doing all the state push
games that are done to avoid having cookies.

Cullen

PS. I wish some things did have limits (particularly the call-id which gets
passed into all kinds of data bases and billing system that do have real
limits.



On 12/5/03 2:20 PM, "Jonathan Rosenberg" <jdrosen@dynamicsoft.com> wrote:

> Folks,
> 
> Based on discussions during the IETF 58 meeting, I've submitted a
> revision to the gruu mechanism document. Until it appears in the
> archives, you can pick up a copy at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-sip-gruu-01.txt
> 
> The changes are as follows:
> 
> * clarified that the registrar needs to return the same gruu in
> registration refreshes, and this requires reliable storage. No
> requirement for returning the same gruu across registrations.
> 
> * clarified that the registrar should ignore any gruu parameter
> provided in the contact header fields of a registration
> 
> * mention that, it is still possible that a gruu changes in a
> registration, in the case where there is a race condition where the
> client thinks its refreshing, but the registration has just expired at
> the registrar. As such, recommend that a UA be prepared to deal with
> such a change.
> 
> * removed text about using this mechanism to replace dialog reuse
> 
> * added some more details on the encryption mechanism, such as
> recommended algorithm and key lengths. Also clearly state that this is
> just one way to do it, you can do it statefully if you want.
> 
> * proxies are prohibited from redirecting a request to a gruu, they
> have to proxy it. If they redirect, you'll ruin any nat traversal
> benefits associated with gruus.
> 
> * clarified that gruus don't provide sufficient privacy services, and
> added a reference to the privacy spec
> 
> * removed the notion of locally generated gruus. The text now says you
> need to use the registration mechanism in the draft to obtain a gruu.
> The result is the end of e2e signaling. It also mentions that a new
> specification is forthcoming which will address this limitation.
> 
> 
> At this point, there are no known open issues. I would like to see if
> there is consensus to adopt this item as a work item of the sip
> working group. I do not believe we took such a poll during the
> meeting. Chairs - can you assist?
> 
> 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 exim@www1.ietf.org  Wed Dec 31 16:00:57 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25506
	for <sip-archive@odin.ietf.org>; Wed, 31 Dec 2003 16:00:57 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbnS8-0002zR-Te
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:00:29 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBVL0SWB011433
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:00:28 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbnRl-0002xK-9O; Wed, 31 Dec 2003 16:00:05 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AbnRN-0002wO-Jk
	for sip@optimus.ietf.org; Wed, 31 Dec 2003 15:59:41 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25483
	for <sip@ietf.org>; Wed, 31 Dec 2003 15:59:39 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbnRM-0000q0-00
	for sip@ietf.org; Wed, 31 Dec 2003 15:59:40 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbnPo-0000oB-00
	for sip@ietf.org; Wed, 31 Dec 2003 15:58:07 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbnON-0000m5-00
	for sip@ietf.org; Wed, 31 Dec 2003 15:56:35 -0500
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBVKu2mR007922;
	Wed, 31 Dec 2003 15:56:02 -0500 (EST)
Message-ID: <3FF337DD.1090001@dynamicsoft.com>
Date: Wed, 31 Dec 2003 15:55:57 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
CC: sip@ietf.org
Subject: Re: [Sip] Updated gruu mechanism spec
References: <BC170352.2AD3B%fluffy@cisco.com>
In-Reply-To: <BC170352.2AD3B%fluffy@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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit



Cullen Jennings wrote:

> I feel this should be adopted as a WG time with new milestone.
> 
> One curiosity question about the GRID parameter - it says that "MUST NOT
> exceed 128 characters". I was wondering why this was added.

Just as a general bound on size. This has been a real problem in the 
past (not defining size limits, and having implementations assume 
particular ones anyway).

> I'm not really
> against it but it struck me as inconsistent with all the the other things in
> SIP which have no limit. 128 is also fairly low for doing all the state push
> games that are done to avoid having cookies.

Thats probably true. I'll remove the limit.

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Wed Dec 31 16:34:35 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26430
	for <sip-archive@odin.ietf.org>; Wed, 31 Dec 2003 16:34:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Abnyh-00048S-MB
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:34:07 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBVLY7jo015869
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:34:07 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Abnyb-00047Q-JL; Wed, 31 Dec 2003 16:34:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Abny1-00044a-06
	for sip@optimus.ietf.org; Wed, 31 Dec 2003 16:33:25 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26327
	for <sip@ietf.org>; Wed, 31 Dec 2003 16:33:21 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Abnxy-0001bx-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:33:22 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Abnw3-0001Z6-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:31:26 -0500
Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbnuM-0001VQ-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:29:38 -0500
Received: from dynamicsoft.com ([63.113.46.68])
	by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBVLSCmR007930;
	Wed, 31 Dec 2003 16:28:13 -0500 (EST)
Message-ID: <3FF33F67.4040102@dynamicsoft.com>
Date: Wed, 31 Dec 2003 16:28:07 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
CC: "'sip@ietf.org'" <sip@ietf.org>,
        "'jdrosen@dynamicsoft.org'" <jdrosen@dynamicsoft.org.cnri.reston.va.us>,
        "'schulzrinne@cs.columbia.edu'" <schulzrinne@cs.columbia.edu>,
        "'pkzivat@cisco.com'" <pkzivat@cisco.com>
Subject: Re: [Sip] Comments on draft-ietf-sip-callee-caps-01
References: <475FF955A05DD411980D00508B6D5FB00439EF83@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF83@en0033exch001u.uk.lucent.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-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

inline.

Drage, Keith (Keith) wrote:

> I have the following comments and questions on the above draft:
> 
> 1)	Given an indication of support of a specific feature, is there a
> requirement to indicate all other features supported that can be
> indicated using the protocol.

No. The draft doesnt provide strict guidannce on which exact 
parameters to include, except to say that it should provide as much 
information as it can.

> I currently can find no words to
> indicate this one way or another. My preference would be to allow
> support only of those feature tags that an implementation considers
> "useful" for its implementation, but I would be concerned if the
> implementor of a peer entity took the opposite approach and
> insisted that my implementation was non-conformant for this reason.
> As one example, an "isfocus" is probably also an "automata". Is
> there a need to indicate both?

isfocus does imply automata in this case, yes. However, they are 
different things. I dont want to introduce into the spec implicit 
capabilities; that is, the presence of one capability implies another. 
I think thats dangerous.

In terms of your original question, I do not see a need for further 
guidance on what information to include, beyond what the spec says 
already. Are there specific words which you think people will use to 
declare implementations non-compliant because they omitted information?


> 
> 2)	I note that this extension uses the same option-tag as the
> callerprefs extension, i.e. "pref". Apart from using the same
> option-tag, I see no dependency between the two extensions, and it
> would appear completely valid for an implementation to support one
> extension and not the other. I would therefore have expected two
> completely different option-tags, one for each extension. Is there
> a reason for the option-tag reuse, apart from the history that
> these two extensions were originally one extension.

No, the history is the main reason.

I think it does make sense to have them separate. That would require a 
change to caller prefs to define a new tag. Unfortunately, caller 
prefs has just been approved, and at this point I cannot issue a 
revision. Also, this is not a change that can be made during auth48, 
since IANA actions occur before auth48. Therefore, changing this would 
require some kind of special casing here, not exactly sure how. 
Honestly, I'm not sure its worth fixing, given its not a big deal.

So, I would prefer to just keep this as is.

> 
> 3)	Section 10.1 defines a number of feature tags relating to the
> support of media types. The text currently specifies that the use
> of these tags indicates "the device supports xxx as a media type".
> Surely in each case it would be more complete to state that "the
> device supports xxx as a media type, and the selection of that
> media type using SIP and SDP", assuming that that additional
> constraint applies.

This has been clarified in the -03 revision of the document. The 
audio, video, etc. attributes refer specifically to streaming media 
received via RTP or similar. It does not refer to support for bodies 
of those types in SIP messages.

> 
> 4)	Section 10.1.5 mentions floor control protocol as an example.
> Would it not be sensible to avoid using floor control protocols as
> an example until XCON have decided what protocol the floor control
> protocol is, and how its use is negotiated. While I guess this
> could be any floor control protocol, SIP people will automatically
> think XCON for conferences.

OK. I can say something else.

> 
> 5)	Section 10.2.4. Mobility feature. In the past we have had
> discussions about what this meant and whether it was useful. I
> thought in general the conclusion was that it wasn't particularly
> useful. It is certainly not useful if I don't understand what is
> meant by mobility. For example a 3GPP IMS user would be using a
> handset that would normally be regarded as mobile. However the
> mobility is supported entirely by the underlying layers, and SIP
> sees no mobility. 

Thats OK. These things dont need to refer to sip characteristics at all.

> The IP address and all other things remain static
> for the duration of a registration, even if the handset moves (I
> note that one of Gonzalo's drafts talks about session mobility only
> in the context of changing IP addresses). If I put my conference
> server on board an ocean liner, is it mobile or not? So if we keep
> this feature, can we have some more words to indicate what is a
> mobile UA, and what is a fixed one.

Its not really important that there is a really concise, mathematical 
kind of definition. We will always have devices which blur limits and 
make it hard to formulate a definition. I think all that really 
matters is that the user of the device consider that a "mobile 
device", such that if a user wishes to reach them on their mobile, 
thats the device that gets reached.


> 
> 6)	Section 10.2.2. Class. I wonder if there are sufficient values
> here. Will this go the way of the top level domain names, and we
> will need an class=organisation for those phones that are neither
> business or personal.

I think the business/personal distinction is pretty well understood. 
I'm not sure what you mean by organization. Did you mean that phones 
would register things like "class=dynamicsoft.com"?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (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 exim@www1.ietf.org  Wed Dec 31 16:46:42 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26722
	for <sip-archive@odin.ietf.org>; Wed, 31 Dec 2003 16:46:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AboAL-0004sB-69
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:46:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBVLk95I018658
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:46:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AboAG-0004q1-Fr; Wed, 31 Dec 2003 16:46:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Abo9m-0004oQ-53
	for sip@optimus.ietf.org; Wed, 31 Dec 2003 16:45:34 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26678
	for <sip@ietf.org>; Wed, 31 Dec 2003 16:45:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Abo9k-0001sg-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:45:32 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Abo7i-0001po-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:43:29 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Abo5n-0001mn-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:41:27 -0500
Received: from sj-core-1.cisco.com (171.71.177.237)
  by sj-iport-5.cisco.com with ESMTP; 31 Dec 2003 21:41:57 +0000
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBVLejGD029529;
	Wed, 31 Dec 2003 13:40:51 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOW71540;
	Wed, 31 Dec 2003 13:40:44 -0800 (PST)
Date: Wed, 31 Dec 2003 13:41:58 -0800
Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: rohan@cisco.com, Dean Willis <dean.willis@softarmor.com>
To: sip@ietf.org
From: Rohan Mahy <rohan@cisco.com>
Content-Transfer-Encoding: 7bit
Message-Id: <28D8DD84-3BDA-11D8-A0DC-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.553)
Content-Transfer-Encoding: 7bit
Subject: [Sip] WGLC for draft-ietf-sip-resource-priority-01
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

Hello,

I'd like to start WGLC on draft-ietf-sip-resource-priority-01.txt.

	http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority- 
01.txt

WGLC will close on January 24, 2004.

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 exim@www1.ietf.org  Wed Dec 31 16:46:44 2003
Received: from optimus.ietf.org ([132.151.1.19])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26723
	for <sip-archive@odin.ietf.org>; Wed, 31 Dec 2003 16:46:42 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AboAL-0004sZ-80
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:46:09 -0500
Received: (from exim@localhost)
	by www1.ietf.org (8.12.8/8.12.8/Submit) id hBVLk81B018659
	for sip-archive@odin.ietf.org; Wed, 31 Dec 2003 16:46:08 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1AboAE-0004p3-RX; Wed, 31 Dec 2003 16:46:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by optimus.ietf.org with esmtp (Exim 4.20)
	id 1Abo9i-0004oL-J0
	for sip@optimus.ietf.org; Wed, 31 Dec 2003 16:45:30 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26674
	for <sip@ietf.org>; Wed, 31 Dec 2003 16:45:27 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1Abo9g-0001sU-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:45:28 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1Abo7e-0001pe-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:43:25 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1Abo5n-0001mm-00
	for sip@ietf.org; Wed, 31 Dec 2003 16:41:27 -0500
Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBVLeoVM024172;
	Wed, 31 Dec 2003 13:40:50 -0800 (PST)
Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR)
	with ESMTP id AOW71545;
	Wed, 31 Dec 2003 13:40:48 -0800 (PST)
Date: Wed, 31 Dec 2003 13:42:01 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-4-110441480
Mime-Version: 1.0 (Apple Message framework v553)
Cc: rohan@cisco.com, Dean Willis <dean.willis@softarmor.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>,
        "James M. Polk" <jmpolk@cisco.com>
To: sip@ietf.org
From: Rohan Mahy <rohan@cisco.com>
Message-Id: <2B1A3BDE-3BDA-11D8-A0DC-0003938AF740@cisco.com>
X-Mailer: Apple Mail (2.553)
Subject: [Sip] re: WGLC: resource priority
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request@ietf.org?subject=subscribe>


--Apple-Mail-4-110441480
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Below is my review of resource-priority. Detailed comments are below, 
but I have a few general ones:

1. There is no normative description of the behavior of SIP devices 
which receive a particular priority value.  Some specifications needs 
to either specify detailed behavior for specific priority values, or 
the detailed semantics of those values.  I think this belongs in the 
IANA registration of each namespace, but those references are currently 
very thin.  I made some specific comments to this end in the 
appropriate sections.

2. Also, I am curious what the semantics of this header mean in the 
context of SUB/NOT.  Can someone provide an example that makes sense?

3. Finally, the document shows that proxies can modify, insert, and 
delete the RP header. I don't think this is a good idea. Where 
cooperating UAs and proxies need to agree on an RP value, I believe the 
session policy mechanism can be used.  A proxy can reject the message 
for policy reasons (use a lower/higher/specific resource-value) and the 
UA can retry the request with these new values.

thanks,
-rohan

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

detailed comments:

put TOC at the beginning

section 2

suggest
...telephone circuits, IP bandwidth  ^reservations or allocations^...

remove or motivate references to presence

section 3:

"   Implementations MAY change the value offered in the request; in some
    environments, the response value is known to be the same as in the
    request."   ???  what does that mean ???

BNF is wrong (your current syntax would require a leading comma).  do 
this instead:

Resource-Priority = "Resource-Priority" HCOLON Resource-value

Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON
			[Resource-value *(COMMA Resource-value)]

check consolidated bnf for reuse of terms

also, the case of Resource-value is highly unusual.

reword this, it is awkward:

"        We require that even namespaces with only one priority
         value list that value to avoid problems if additional
         priority values are added later."

There may be multiple resource values or, equivalently, multiple
    Resource-Priority header /fields/field values/.

what does it mean to "support" a particular Resource-value?

our current method list is:
INV ACK CAN BYE REG OPT PRA
SUB NOT UPD MSG REF INF PUB

what does RP mean in a SUB or NOT?

where is section 4.2?

section 4.3

add comma here please...
Elements receiving
    requests with namespaces or priority values that they do not
    understand  ^,^ act according to the rules in the next section.

section 4.4:  you should introduce the resource-priority option tag 
(just the tag) back in section 3

section 4.7:  i don't think a proxy should be able to insert, delete, 
or modify the RP header.  This makes it impossible to use e2e on the RP 
headers, which I think will be required.

section 9-12:

option-tags are always lowercase by convention

you should add a note to the RFC editor asking for RFCXXXX to be 
replaced with the RFC number of this document.

please make section 9 be IANA considerations  (start with the text in 
section 12), then under this, create section 9.1 (formerly section 9) 
to register the new headers, section 9.2 (formerly section 10) to 
register the resource-priority header, section 11 becomes 9.3.

include a registration template  (for example)

Namespace:
Description:
Organization Responsible for Change Control of this Namespace:
Priority values (ordered from least priority to greatest priority):
Default priority:
Preempt or Prioritize:
Document Containing Normative Description:
Section Containing Normative Description:
Additional security requirements:

I would also consider including Section B.1 as section 9.4, B.2 -> 9.5, 
B.3 -> 9.6
(IANA will be happy if all the work they have to do is consolidated 
under a single 1st-level section heading).

in any case for the initial registrations, please fill in the template 
for each one; for example:

Namespace: q735
Description: ITU Q.735.3 Multi-level precedence and preemption in SS7
Organization Responsible for Change Control of this Namespace: ITU-T
Priority values (ordered from least priority to greatest priority): 4, 
3, 2, 1, 0
Default priority: 4
Preempt or Prioritize: prioritize
Document Containing Normative Description: ITU-T Q.735.3 [3]
Section Containing Normative Description: ??
Additional security requirements: none

Namespace: dsrn
Description: United States Defense Red Switched Network
Organization Responsible for Change Control of this Namespace: US 
Department of Defense?
Priority values (ordered from least priority to greatest priority):
   routine, priority, immediate, flash, flash-override, 
flash-override-override
Default priority: routine
Preempt or Prioritize: preempt
Document Containing Normative Description: FIPS XXXX ??  [?]
Section Containing Normative Description: ??
Additional security requirements: All implementations must follow the 
certificate management guidelines specified in xxxx [?]



--Apple-Mail-4-110441480
Content-Type: text/enriched;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,


Below is my review of resource-priority. Detailed comments are below,
but I have a few general ones:

<fontfamily><param>Helvetica</param>

1. There is no normative description of the behavior of SIP devices
which receive a particular priority value.  Some specifications needs
to either specify detailed behavior for specific priority values, or
the detailed semantics of those values.  I think this belongs in the
IANA registration of each namespace, but those references are
currently very thin.  I made some specific comments to this end in the
appropriate sections.


2. Also, I am curious what the semantics of this header mean in the
context of SUB/NOT.  Can someone provide an example that makes sense?


3. Finally, the document shows that proxies can modify, insert, and
delete the RP header. I don't think this is a good idea. Where
cooperating UAs and proxies need to agree on an RP value, I believe
the session policy mechanism can be used.  A proxy can reject the
message for policy reasons (use a lower/higher/specific
resource-value) and the UA can retry the request with these new values.


thanks,

-rohan


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


detailed comments:


put TOC at the beginning


section 2


suggest 

...telephone circuits, IP bandwidth  ^reservations or allocations^...


remove or motivate references to presence


section 3:


"   Implementations MAY change the value offered in the request; in
some

   environments, the response value is known to be the same as in the

   request."   ???  what does that mean ???


BNF is wrong (your current syntax would require a leading comma).  do
this instead:


Resource-Priority = "Resource-Priority" HCOLON Resource-value


Accept-Resource-Priority = "Accept-Resource-Priority" HCOLON

			[Resource-value *(COMMA Resource-value)] 


check consolidated bnf for reuse of terms


also, the case of Resource-value is highly unusual.


reword this, it is awkward:


"        We require that even namespaces with only one priority

        value list that value to avoid problems if additional

        priority values are added later."


There may be multiple resource values or, equivalently, multiple

   Resource-Priority header /fields/field values/.


what does it mean to "support" a particular Resource-value?


our current method list is:

INV ACK CAN BYE REG OPT PRA 

SUB NOT UPD MSG REF INF PUB 


what does RP mean in a SUB or NOT?


where is section 4.2?


section 4.3


add comma here please...

Elements receiving

   requests with namespaces or priority values that they do not

   understand  ^,^ act according to the rules in the next section.


section 4.4:  you should introduce the resource-priority option tag
(just the tag) back in section 3


section 4.7:  i don't think a proxy should be able to insert, delete,
or modify the RP header.  This makes it impossible to use e2e on the
RP headers, which I think will be required.


section 9-12:


option-tags are always lowercase by convention


you should add a note to the RFC editor asking for RFCXXXX to be
replaced with the RFC number of this document.


please make section 9 be IANA considerations  (start with the text in
section 12), then under this, create section 9.1 (formerly section 9)
to register the new headers, section 9.2 (formerly section 10) to
register the resource-priority header, section 11 becomes 9.3.   


include a registration template  (for example)


Namespace:

Description:

Organization Responsible for Change Control of this Namespace:

Priority values (ordered from least priority to greatest priority):

Default priority:

Preempt or Prioritize:

Document Containing Normative Description:

Section Containing Normative Description:

Additional security requirements:


I would also consider including Section B.1 as section 9.4, B.2 ->
9.5, B.3 -> 9.6

(IANA will be happy if all the work they have to do is consolidated
under a single 1st-level section heading).


in any case for the initial registrations, please fill in the template
for each one; for example:


Namespace: q735

Description: ITU Q.735.3 Multi-level precedence and preemption in SS7

Organization Responsible for Change Control of this Namespace: ITU-T

Priority values (ordered from least priority to greatest priority): 4,
3, 2, 1, 0

Default priority: 4

Preempt or Prioritize: prioritize

Document Containing Normative Description: ITU-T Q.735.3 [3]

Section Containing Normative Description: ??

Additional security requirements: none


Namespace: dsrn

Description: United States Defense Red Switched Network

Organization Responsible for Change Control of this Namespace: US
Department of Defense?

Priority values (ordered from least priority to greatest priority): 

  routine, priority, immediate, flash, flash-override,
flash-override-override

Default priority: routine

Preempt or Prioritize: preempt

Document Containing Normative Description: FIPS XXXX ??  [?]

Section Containing Normative Description: ??

Additional security requirements: All implementations must follow the
certificate management guidelines specified in xxxx [?]



</fontfamily>
--Apple-Mail-4-110441480--


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