Re: [MEDIACTRL] Call Flows Document

I agree that a document with illustrative/sample call flows should be 
distinct from any "torture test" or "interoperability spec".

And the illustrative call flows are of the greatest immediate interest, at 
least for me.

Janet

Computer Sciences Corporation 
Registered Office: 3170 Fairview Park Drive, Falls Church, Virginia 22042, 
USA
Registered in Nevada, USA No: C-489-59

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. 
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to 
any order or other contract unless pursuant to explicit written agreement 
or government initiative expressly permitting the use of e-mail for such 
purpose.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

"DRAGE, Keith \(Keith\)" <drage@alcatel-lucent.com> 
Sent by: mediactrl-bounces@ietf.org
07/31/2008 04:50 AM

To
"Eric Burger" <eburger@standardstrack.com>, <mediactrl@ietf.org>
cc

Subject
Re: [MEDIACTRL] Call Flows Document

Two points:

1)    If a document is produced, and no matter whether it is author 
initiated or WG initiated, it should be subject to the same care and 
review that the specifications receive. If we cannot give it that, we 
stand a chance of having an inaccurate document with all the problems 
listed. If the document is not going to get the WG care and review, then 
we should not proceed with the document.

2)    In regard to Q1 on the type of document, I don't object to producing 
any of these document (subject to the constraints above), but I believe it 
is inappropriate to combine 1a) with 1b) or 1c). These are two separate 
kinds of document and should be published separately. The first would be 
expected to indicate the normal operation. Test and interoperability 
documents even as flows are more likely to show the abnormal cases.

regards

Keith

From: mediactrl-bounces@ietf.org [mailto:mediactrl-bounces@ietf.org] On 
Behalf Of Eric Burger
Sent: Wednesday, July 30, 2008 6: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._______________________________________________
MEDIACTRL mailing list
MEDIACTRL@ietf.org
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl