Re: [MEDIACTRL] Call Flows Document

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.