Mary,
Don't get me wrong - I'm not passing judgement on the value of the call
flow specs, or on any other spec for that matter. I'm just trying to
keep the scope of this document to a point where there is an objective
definition we can agree to which defines the contents of the document.
The current definition focuses squarely on protocol specs - extensions
and object specs and the like. Those collected together define the
functionality provided by SIP. I do agree that a BCP can, for all
intents and purpsoes, be thought of as a protocol spec in that it
normatively defines behavior. We have a BCP in there now (3pcc).
Whats interesting is that the call flow specs (3665, 3666) are BCP, but
frankly I'm not sure why. RFC 3665 for example contains the definitions
of RFC 2119 terms, but never once uses any of them. To me, a BCP is a
BCP and not informational because it has such terms - it describes
behavior in some way.
We could choose to expand the definition of the scope of the hitchhikers
guide to include example call flow documents, whether they be
informational or BCP. That would throw in a few more (torture tests for
example). The main question I would ask is whether we view those kinds
of informational documents as different from ones like RFC 5057
(multiple dialog usage) which, I would argue, is closer to what BCP
ought to be, in terms of defining behaviors explicitly that are
non-obvious or unspecified in the base specs.
-Jonathan R.
Mary Barnes wrote:
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
