Re: [MEDIACTRL] Call Flows Document
Lorenzo Miniero <lorenzo.miniero@unina.it> Thu, 31 July 2008 17:38 UTC
Return-Path: <mediactrl-bounces@ietf.org>
X-Original-To: mediactrl-archive@optimus.ietf.org
Delivered-To: ietfarch-mediactrl-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD183A68E0; Thu, 31 Jul 2008 10:38:03 -0700 (PDT)
X-Original-To: mediactrl@core3.amsl.com
Delivered-To: mediactrl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7E93A6892 for <mediactrl@core3.amsl.com>; Thu, 31 Jul 2008 10:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 ZcRLALviU4C5 for <mediactrl@core3.amsl.com>; Thu, 31 Jul 2008 10:38:01 -0700 (PDT)
Received: from webmail.unina.it (webmail.unina.it [192.132.34.212]) by core3.amsl.com (Postfix) with ESMTP id DA2333A6932 for <mediactrl@ietf.org>; Thu, 31 Jul 2008 10:38:00 -0700 (PDT)
Received: from webmail.unina.it (localhost [127.0.0.1]) by webmail.unina.it (8.14.0/8.14.0) with ESMTP id m6VHcCjU030689; Thu, 31 Jul 2008 19:38:12 +0200
Received: (from apache@localhost) by webmail.unina.it (8.14.0/8.14.0/Submit) id m6VHcBUW030685; Thu, 31 Jul 2008 19:38:11 +0200
X-Authentication-Warning: webmail.unina.it: apache set sender to lorenzo.miniero@unina.it using -f
Received: from 130.129.19.107 ([130.129.19.107]) by webmail.unina.it (Horde MIME library) with HTTP; Thu, 31 Jul 2008 19:38:11 +0200
Message-ID: <20080731193811.8nu78amv40ko0wc0@webmail.unina.it>
Date: Thu, 31 Jul 2008 19:38:11 +0200
From: Lorenzo Miniero <lorenzo.miniero@unina.it>
To: "DOLLY, MARTIN C, ATTLABS" <mdolly@att.com>
References: <41D05D54-443E-4A32-86F6-1728B51061A1@standardstrack.com> <14C85D6CCBE92743AF33663BF5D24EBA56E2A9@gaalpa1msgusr7e.ugd.att.com>
In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA56E2A9@gaalpa1msgusr7e.ugd.att.com>
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] Call Flows Document
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes"
Sender: mediactrl-bounces@ietf.org
Errors-To: mediactrl-bounces@ietf.org
Just to clarify, we've so far already tried to keep the call flows document synced with the mediactrl drafts as well as we could. Of course, when IETF meetings and the like are on their way, there are deadlines to abide by, and this applies to both normative documents and our work. This means that, if drafts are uploaded like one day before the deadline, we can't possibly update ours accordingly in time; at least not as long as we won't have ten or more engineers to whip and force to do the dirty work for us, which is unlikely to ever happen ;) The next version of the draft will have the call flows updated with respect to the mixer draft too, which we already implemented anyway. Lorenzo Quoting "DOLLY, MARTIN C, ATTLABS" <mdolly@att.com>: > Greetings, > > I agree with Spencer that this should be a WG item, but not now, as to > focus cycles on the other documents. As the other documents, that would > feed into this document become more stable, we would make this a WG > item. > > Whether a individual or WG item, it should get meeting time. > > Common sense dictates, as many folks have stated, that the document > needs to be updated to be in-sync with the normative drafts. > > Martin > > ________________________________ > > From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On > Behalf Of Eric Burger > Sent: Wednesday, July 30, 2008 1:48 PM > To: mediactrl@ietf.org > Subject: [MEDIACTRL] Call Flows Document > > > At the meeting today, we discussed at length the issues around adding > <http://www.ietf.org/internet-drafts/draft-miniero-mediactrl-escs-02.txt >> , "Media Control Channel Framework (CFW) Call Flow Examples" as a work > group item. > > > To recap: > 1. Just about everyone stated it is extremely useful to have call flows. > a. Important for us as protocol developers to debug the > specification, > e.g., "Oops - we forgot that message" > b. Important for some developers with interpretation of the > specifications > c. Important for interoperability testing > > > 2. Many people pointed out call flow documents have their drawbacks. > a. Some people will code to the call flows and not to the > specification. > i. If the call flows are wrong, the developer will code the wrong > thing. > ii. Call flows cannot capture the nuances of the protocol, such as > non-deterministic message order or legal, but not shown in a > call flow, messages that pop up > b. When people see a call flow document, they may not read the > specification at all. > c. When people see a Work Group *draft*, they may consider it to be > a stable, authoritative reference. > > > It would be safe to say that no matter what we decide here, there will > be a call flows document. The questions to decide are: > > > 1. What document(s) will we produce? Will we produce: > a. A basic call flows document, illustrating some examples of > how the protocol works (see draft-ietf-sipping-service-examples-15 > for an example) > b. A torture test document, illustrating examples of malformed > messages or messages seriously out of order, that stacks > must not barf on (see RFC 4475 for an example) > c. A test suite document, describing how to achieve interoperability > (see > http://www.msforum.org/techinfo/approved/MSF-IA-SIP.015-FINAL.pdf) > d. A plurality of a, b, or c > e. All of a, b, and c > > > Note all call flow documents are Informational (not Normative) by > definition. > > > 2. Will the work group produce these documents? No matter what, > individuals > from the work group will write the document(s), and people in the > work > group (many have already volunteered) will review the document(s). > a. Do they need to be Work Group documents? > b. Is it OK for them to be Individual documents, for now. > > > Please RSVP with your views on the above questions. > > > Thanks. > -- Lorenzo Miniero, Junior Researcher Dipartimento di Informatica e Sistemistica Universita' degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 Email: lorenzo.miniero@unina.it _______________________________________________ MEDIACTRL mailing list MEDIACTRL@ietf.org https://www.ietf.org/mailman/listinfo/mediactrl Supplemental Web Site: http://www.standardstrack.com/ietf/mediactrl
- Re: [MEDIACTRL] Call Flows Document DRAGE, Keith (Keith)
- [MEDIACTRL] Call Flows Document Eric Burger
- Re: [MEDIACTRL] Call Flows Document Spencer Dawkins
- Re: [MEDIACTRL] Call Flows Document Mary Barnes
- Re: [MEDIACTRL] Call Flows Document Janet P Gunn
- Re: [MEDIACTRL] Call Flows Document Even, Roni
- Re: [MEDIACTRL] Call Flows Document spromano
- Re: [MEDIACTRL] Call Flows Document Dan York
- Re: [MEDIACTRL] Call Flows Document DOLLY, MARTIN C, ATTLABS
- Re: [MEDIACTRL] Call Flows Document Even, Roni
- Re: [MEDIACTRL] Call Flows Document Lorenzo Miniero