I fully agree with Mary and wish we would have similar call flow examples for SIMPLE as well instead of a guide only.
The hitch-hikers guides without references to (1) call flow examples and yes, (2) OS code seems like a band-aid instead of the real thing. Call flow examples and OS code are IMHO the only proof the guides are anchored in reality. Example: IETF meetings use Jabber instead of SIMPLE and no guide will change this fact. This makes me question the usefulness of these hitchhikers guides for SIP and SIMPLE, unless they have references to call flow examples and OS code or similar. I suggest both guides for SIP and SIMPLE to be re-edited with such references. Thanks, Henry -----Original Message----- From: Mary Barnes [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 14, 2007 6:49 AM To: Jonathan Rosenberg; Peter Saint-Andre Cc: sip; [EMAIL PROTECTED] Subject: [RAI] RE: [Sip] RAI-ART Review Comments fordraft-ietf-sip-hitchhikers-guide Jonathan, I honestly think that not having the call flows, which are BCPs, leaves a huge gap in the document. And, I think not having them is contrary to these statements in the hitchiker's guide (from the intro): "It is an informational document, meant to guide newcomers, implementors and deployers to the SIP suite of specifications." And (in the paragraph following the text you extracted): "Best Current Practices are included when they normatively define mechanisms for accomplishing a task." IMHO, that is the case with all the call flow BCPs, per the basic definition of BCP in RFC 2026: A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. At a minimum, basic call flows fits into this category because the ones in RFC 3261 are not comprehensive. If we don't tell newcomers about the call flows in this document, they will likely miss them, since the whole point of this document is to help them navigate the specs. It would be okay of the call flows were referenced in the other documents, since more astute developers would have the sense to look at referenced docs, as well, many of them are not referenced. For example, the only document that seems to reference basic call flows is RFC 4083 (3GPP requirements). If the reluctance to include the call flow BCPs is a concern that they no longer reflect "Best" current practices, then we need to start updating those documents or we need to obsolete them. I also just noticed that one BCP that wasn't mentioned yet was RFC 4579. It would be difficult to figure out how to put together a SIP based conferencing implementation based only on the other docs in section 8 (conferencing) without the call flow document. Regards, Mary. -----Original Message----- From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 14, 2007 12:21 AM To: Peter Saint-Andre Cc: sip; [EMAIL PROTECTED]; Stucker, Brian (RICH1:AR00) Subject: Re: [Sip] RAI-ART Review Comments for draft-ietf-sip-hitchhikers-guide The call flow documents do not meet the current criteria defined by hitchhikers for inclusion. That criteria is: It is very difficult to enumerate the set of SIP specifications. This is because there are many protocols that are intimately related to SIP and used by nearly all SIP implementations, but are not formally SIP extensions. As such, this document formally defines a "SIP specification" as: o Any specification that defines an extension to SIP itself, where an extension is a mechanism that changes or updates in some way a behavior specified in RFC 3261 o Any specification that defines an extension to SDP whose primary purpose is to support SIP o Any specification that defines a MIME object whose primary purpose is to support SIP Example call flows do not meet this criteria. -Jonathan R. Peter Saint-Andre wrote: > Brian Stucker wrote: > > <snip/> > > Sorry to hijack this thread, but I'd like to second a comment that > Mary Barnes made during the WGLC: > > http://www1.ietf.org/mail-archive/web/sip/current/msg20981.html > > *** > > It seems that all the call flow BCPs are missing and I do think those > are really important and should be included in this document. The > only BCP (type (B) document) listed in this document is 3PCC. The > basic call flow document (RFC 3665) should be listed in section 3 > (Core SIP). The PSTN call flows (RFC 3666, BCP 76) should be in PSTN > Interworking section 4. The SIPPING NAT scenarios document should be > in the NAT section 6. These docs are all icing on the cake IMHO and > help to guide implementers in using all the other docs. > > *** > > I agree that the call flow documents are very useful and that a > reference to them would be a good thing. > > Peter -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems [EMAIL PROTECTED] FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ RAI mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/rai _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
