[MEDIACTRL] Call Flows Document

Eric Burger <eburger@standardstrack.com> Wed, 30 July 2008 17:47 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 C7EB528C39E; Wed, 30 Jul 2008 10:47:36 -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 8494C28C39E for <mediactrl@core3.amsl.com>; Wed, 30 Jul 2008 10:47:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level:
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.226, 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 PVJsP7i3BVvG for <mediactrl@core3.amsl.com>; Wed, 30 Jul 2008 10:47:33 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19b.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 025BD3A6BCC for <mediactrl@ietf.org>; Wed, 30 Jul 2008 10:47:32 -0700 (PDT)
Received: from [130.129.20.50] (port=58574 helo=dhcp-130-129-20-50.meeting.ietf.org) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <eburger@standardstrack.com>) id 1KOFlo-0001Gw-8F for mediactrl@ietf.org; Wed, 30 Jul 2008 10:47:28 -0700
Message-Id: <41D05D54-443E-4A32-86F6-1728B51061A1@standardstrack.com>
From: Eric Burger <eburger@standardstrack.com>
To: mediactrl@ietf.org
Mime-Version: 1.0 (Apple Message framework v926)
Date: Wed, 30 Jul 2008 18:47:31 +0100
X-Mailer: Apple Mail (2.926)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [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-Type: multipart/mixed; boundary="===============0698238956=="
Sender: mediactrl-bounces@ietf.org
Errors-To: mediactrl-bounces@ietf.org

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.
_______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl