[Per Keith's suggestion starting a new thread, copied from last one] Yes Paul, that is what I was trying to get at. Sorry if all this was already discussed and closed. Do we have a comaparitive between the two approaches from past? The reason I brought it out was that there are several similarities in where we are going with info events and 3265. I hope we do not undermine the usage of SIP events. As an example if one comes up with a brand new application that has some small data to be transferred between UAs and the session is INVITE based then which approach should one take? Will we have clear guidelines or leave it open? IMHO overlapping semantics is also not very good for interoperability. Is the legacy (mis)use of INFO the most compelling reason for this approach of bringing it into pFrom sip-bounces at ietf.org Wed Oct 29 10:06:23 2008 Return-Path: <sip-bounces at ietf.org> X-Original-To: sip-web-archive at optimus.ietf.org Delivered-To: ietfarch-sip-web-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84DE83A6841; Wed, 29 Oct 2008 10:06:23 -0700 (PDT) X-Original-To: sip at core3.amsl.com Delivered-To: sip at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282373A681B for <sip at core3.amsl.com>; Wed, 29 Oct 2008 10:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 OwOCMkYcvHmM for <sip at core3.amsl.com>; Wed, 29 Oct 2008 10:06:21 -0700 (PDT) Received: from mail-gx0-f18.google.com (mail-gx0-f18.google.com [209.85.217.18]) by core3.amsl.com (Postfix) with ESMTP id C4DAE3A635F for <sip at ietf.org>; Wed, 29 Oct 2008 10:06:20 -0700 (PDT) Received: by gxk11 with SMTP id 11so3063746gxk.13 for <sip at ietf.org>; Wed, 29 Oct 2008 10:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=+A8WGfOaaRViDaA2fGlPBaOcQvbAAIvKoN8DFueqito=; b=KYkWGt1NmtkBRyBBgJEC+ivyh//T0bg9hBmsjRz7LoxGak9pRU9q2sdGbEB64dAL5h OznF7bqbj5lvpvw5ca9/msrYP8GXWF1J6oQRxv9pEnHeuKQp82h8pPNyIVcj4ezYO6px rY71cwQD3cWzq0wCwUCyCy2wY/Vv5h7cT5w4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=TroVMlc9zRMoqT9zaiOMB1ycQGOwk1z6wdfXh4+5Md2bAzgWvo7pmuj6njNOia4fm2 9zgY0onTzoKBcST2DwoaDrOrl2hz/fb4yymB82HUYB/FCGlzxZHS+r9rigZHJoDQL7xS 6k0fKDgp/axtCs8b5zlcuPsrwSoIvF4H3da70= Received: by 10.142.199.16 with SMTP id w16mr4133584wff.268.1225299978292; Wed, 29 Oct 2008 10:06:18 -0700 (PDT) Received: by 10.142.105.18 with HTTP; Wed, 29 Oct 2008 10:06:18 -0700 (PDT) Message-ID: <21964a950810291006i6940f9fdi1f5fcf05a28a307d at mail.gmail.com> Date: Wed, 29 Oct 2008 13:06:18 -0400 From: "Nasir Khan" <nkhan.sip at gmail.com> To: "SIP IETF" <sip at ietf.org> MIME-Version: 1.0 Subject: [Sip] draft-ietf-sip-info-events-00 using RFC 3265 instead X-BeenThere: sip at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Session Initiation Protocol <sip.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request at ietf.org?subject=unsubscribe> List-Post: <mailto:sip at ietf.org> List-Help: <mailto:sip-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1317946497==" Sender: sip-bounces at ietf.org Errors-To: sip-bounces at ietf.org
If that is your point, we have been down that path already. Many of us have taken that position in the past (and may still believe it today), but there were many arguments that that approach is to heavy weight. Evidence of that is the continued use of info for DTMF even though we have an event package for that.
Paul
Nasir Khan wrote:
Maybe it warrants a separate thread but I would like to discuss section 7.1.3 of this draft where 3265 is talked about as an alternative.
Since we are talking about the notion of well defined info packages and the INFO messages
will carry information as a result of an event like an ISUP event or DTMF event (the name of the draft itself has "event" in it), then the two User Agents can very well subscribe to these events and use the notifications for the information exchange.
This will automatically inherit all the good work done around notification framework and will lay to rest lot of questions and perhaps save some re-invention.
Regards
Nasir
--
Get the most comprehensive open source SIP application testing framework at http://sipper.agnity.com
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip