Re: [MEDIACTRL] Call Flows Document

[Dan York <[e-mail]>]

I'll agree with Keith on his two points here.  For all the reasons  
outlined by Eric, a call flows document needs to stay locked in sync  
with the specification so that it *is* an accurate representation of  
the specification.  If at some point in time we either revise the main  
MCCF specification, or extend/change it with other RFCs, we need to  
ensure that the Call Flows document is revised so that it reflects the  
current specification(s).

In my opinion, any document that helps implementors better understand  
*how* to implement our specifications is a good thing to have around.   
If our end goal is to have our protocols widely used and deployed,  
anything that helps guide implementors is good.  Call flows, sample  
implementations (such as that of the Univ. of Napoli team), "HOWTO"  
documents, etc., all are good to have.  It's similar to any vendor's  
product release... when the product is launched, there is usually  
accompanying training classes, presentations, etc. that teach/show how  
to use the new product.

Obviously, though, those "implementation aids" do have to accurately  
represent the current state of the specification and so in committing  
to create such a document, we are also implicitly committing to keep  
that document up-to-date.

My 2 cents,
Dan

On Jul 31, 2008, at 4:50 AM, DRAGE, Keith (Keith) wrote:

> 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

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [e-mail]
Phone: [phone]  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free

_______________________________________________
MEDIACTRL mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl