Re: [sip-ops] SIP OPTIONS "ping"

Brian Rosen <br@brianrosen.net> Thu, 12 August 2010 12:44 UTC

Return-Path: <br@brianrosen.net>
X-Original-To: sip-ops@core3.amsl.com
Delivered-To: sip-ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00FF23A68AB for <sip-ops@core3.amsl.com>; Thu, 12 Aug 2010 05:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level:
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18sAzBixPUHD for <sip-ops@core3.amsl.com>; Thu, 12 Aug 2010 05:44:56 -0700 (PDT)
Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id D261A3A6868 for <sip-ops@ietf.org>; Thu, 12 Aug 2010 05:44:55 -0700 (PDT)
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.60.50]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <br@brianrosen.net>) id 1OjXA0-0005dE-V7; Thu, 12 Aug 2010 07:45:29 -0500
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-69-514730923"
From: Brian Rosen <br@brianrosen.net>
In-Reply-To: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com>
Date: Thu, 12 Aug 2010 08:45:25 -0400
Message-Id: <736CC4E3-7489-42F6-9E68-1C6EA51C0503@brianrosen.net>
References: <053401cb39dd$44070ee0$cc152ca0$@packetizer.com>
To: "Paul E. Jones" <paulej@packetizer.com>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
Cc: sip-ops@ietf.org, Hadriel Kaplan <HKaplan@acmepacket.com>, sip-implementors@lists.cs.columbia.edu
Subject: Re: [sip-ops] SIP OPTIONS "ping"
X-BeenThere: sip-ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Operations <sip-ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip-ops>, <mailto:sip-ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-ops>
List-Post: <mailto:sip-ops@ietf.org>
List-Help: <mailto:sip-ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-ops>, <mailto:sip-ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2010 12:44:57 -0000

I think this is needed, and I would go for informational.  While I sort of understand that you are "pushing" the definition of OPTIONS, if it was PS, you wouldn't update any RFCs, right?

Brian

On Aug 12, 2010, at 1:14 AM, Paul E. Jones wrote:

> Folks,
>  
> Gonzalo and I produced an Internet Draft aiming at trying to bring some consistency to the way in which SIP user agents implement an OPTIONS “ping” procedure.  It seems that a very large number of vendors do this, but unfortunately, there seems to be little consistency.
>  
> Initially, we positioned the document as a standards track RFC, since this essentially builds on RFC 3261.  However, there was some pushback from folks in the IETF for a variety of reasons, not the least of which is the fact that there is no working group chartered to do the work.  We don’t feel this one draft warrants the creation of a working group.
>  
> So, we’ve got three options we can consider:
> 1)      Forge ahead outside of a working group
> 2)      Change the status of the draft to Informational
> 3)      Forget about the draft and let every SIP device do it the way they want, throwing hope of consistency out the window
>  
> (Yeah, you can tell I prefer not to go for the third option.)
>  
> In any case, I’d like to get feedback from the on the SIP operators and SIP implementers lists.  Do you think it’s worth trying to address this issue?  If so, which option do you think we should pursue?
>  
> Note that we’re certainly open to feedback on the draft.  I’d prefer it to have a few more “MUST” statements in the text, rather than “SHOULD”.  But, we need to find that right balance:
> http://tools.ietf.org/html/draft-jones-sip-options-ping
>  
> Paul
>  
> _______________________________________________
> sip-ops mailing list
> sip-ops@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-ops