Re: [MEDIACTRL] Call Flows Document

["DRAGE, Keith \(Keith\)" <[e-mail]>]

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: [e-mail]
[mailto:[e-mail]] On Behalf Of Eric Burger
	Sent: Wednesday, July 30, 2008 6:48 PM
	To: [e-mail]
	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
[e-mail]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl