Re: [MEDIACTRL] Call Flows Document

Yeah, Eric and I talk, from time to time...

Just to add my concern as one half of the working group chairship, what I really want to see happen is that such a document is produced, but that we do not adopt it so quickly that having the six-or-so reviewers who volunteered focused on this document will not interfere with the currently chartered deliverables.

It would be most helpful if we got through the re-WGLCs and WGLCs that we talked about today, REALLY FAST and with good quality, so we will have mostly-cleared decks really soon and can focus on this excellent document, and on the currently-chartered Media Resource Broker.

So please keep an eye out for WGLC e-mail from myself and from Eric, because our working group milestone list could be dramatically different by the end of September if we really focus - or dramatically the same by the end of 2008, if we just cycle once per IETF meeting.

Thanks,

Spencer
  ----- Original Message ----- 
  From: Eric Burger 
  To: mediactrl@ietf.org 
  Sent: Wednesday, July 30, 2008 12:47 PM
  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.

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

  _______________________________________________
  MEDIACTRL mailing list
  MEDIACTRL@ietf.org
  https://www.ietf.org/mailman/listinfo/mediactrl
  Supplemental Web Site:
  http://www.standardstrack.com/ietf/mediactrl