[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] My notes on draft-rosenberg-sip-hitchhikers-guide-00
Hi, Jonathan,
I've been through this draft, and had some comments that I wanted to pass
along. Some of them may be relevant for WG discussion of the draft, so I'm
posting to the list.
I want to preface everything I type below with "thank you for putting this
together".
Spencer
Abstract
The Session Initiation Protocol (SIP) is the subject of numerous
specifications that have been produced by the IETF. It can be
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP. Don't Panic! This
specification serves as a guide to the SIP RFC series. It lists the
specifications under the SIP umbrella, briefly summarizes each, and
groups them into categories.
Spencer: Just as a general thing - I love the Douglas Adams references, and
agree with your suggestion from IETF 65 that you need more of them, but
since (gasp!) there are people who may not have read them, there are a
couple of places that I would suggest handling them differently - and this
is one place. "Don't Panic!" appears in the abstract and in the
Introduction, and I'd suggest removing it from the Abstract. (And
"Hitchhiker's Guide" should be apostrophied, I think
1. Introduction
The Session Initiation Protocol (SIP) [1] is the subject of numerous
specifications that have been produced by the IETF. It can be
Spencer: it seems fair to point out that, in addition to the (mostly)
approved specifications that are described in this document, there are
literally hundreds of proposals for SIP and extensions that are not included
in this document because they are still being produced.
difficult to locate the right document, or even to determine the set
of Request for Comments (RFC) about SIP. Don't Panic! This
Spencer: I don't have anything in my IETF 65 notes about adding the Douglas
Adams book(s) as references, but thought I remembered this being mentioned,
and I agree with adding it (for a couple of reasons). If you add the Douglas
Adams book(s) as references, it would be helpful to use the reference to
"tag" quotes and humorous references. "Don't Panic!" really doesn't need
this in the Introduction, but there is at least one joke futher down that
does (see comment below). And I believe I heard a suggestion to use
reference [42] as the Douglas Adams reference number, at IETF 65, so the
text would be "Don't Panic! [42]"...
specification serves as a guide to the SIP RFC series. It lists the
specifications under the SIP umbrella. For each specification, a
paragraph or so description is included that summarizes the purpose
of the specification. Each specification also includes a letter that
Spencer: actually, there are a bunch of specifications that don't have an
associated letter. If it's helpful, I could chase these down, but it looked
like sending you diffs would be tedious for you to apply. We can talk.
designates its category in the standards track [2]. These values
are:
S: Standards Track (Proposed Standard, Draft Standard, or Standard)
E: Experimental
B: Best Current Practice
I: Informational
The specifications are grouped together by topic. Typically, SIP
extensions fit naturally into topic areas, and implementations
interested in a particular topic often implement many or all of the
specifications in that area.
This document itself is not an update to RFC 3261 or an extension to
SIP. It is an informational document, meant to guide newcomers and
implementors to the SIP suite of specifications.
Spencer: At this stage of the game, I'm assuming that deployers are as
likely to find this document useful as implementors. Are they part of the
target audience? I have a couple of notes further down that assume "yes".
2. Scope of this Document
Spencer: this section should probably be split - part of it is about "scope
of the document", and part of it defines "the other specifications that
aren't SIP, but matter a lot". I'd suggest splitting it before the last line
of the following paragraph.
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 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. This is in contrast to
the "SIP family of specifications", which represent the set of
specifications that define protocols that are integral parts of any
SIP deployment, but are not SIP extensions per se. The SIP family of
specifications includes the following specifications and their
respective extensions:
Spencer: It's definitely worth a section header that says "Related
Specifications" above these documents.
Spencer: it would be good to pick between "always mention the current
specification first" and "always mention the historical specification
first". There aren't many places where it's confusing, but the following
paragraph confused me:
RFC 3550: Real Time Transport Protocol (RTP) RTP [4] is the
specification that started it all. It is the first in a long line
of IETF specifications related to multimedia communications. Its
initial version, RFC 1889 [3] was first specified in January of
1996. RTP is used to carry multimedia traffic, including voice,
video and text, and is set up by SIP. There are countless
extensions and payload formats (possibly as many as 42) defined
for RTP.
Spencer: Perhaps "RFC 3550: Real Time Transport Protocol (RTP) RTP [4] is
the latest version of the specification that started it all - RFC 1889 [3],
the first in a long line of IETF specifications related to multimedia
communications, first specified in January 1996. RTP is used to carry
multimedia traffic, including voice, video and text, and is set up by SIP.
There are countless extensions and payload formats (possibly as many as 42)
defined for RTP."
Spencer: "possibly as many as 42" is funny, but I am more comfortable if you
have adopted a reference to the Douglas Adams book(s), and have something
like ("possibly as many as 42 [42])" in this paragraph. The current text is
just a little too deadpan for people who aren't fluent in Vogon.
RFC 3219: Telephony Routing over IP (TRIP) TRIP [15] defines a
mechanism for exchanging SIP routes between administrative
domains. Its derived from BGP.
Spencer: s/Its/It's/, or s/Its/TRIP is/
Despite the importance of the SIP family of specifications, this
Spencer: This seems slightly off - perhaps "Despite the importance of
related specifications, ..." - aren't you saying that there is more to doing
SIP than just doing what the SIP family of specifications describes?
document concerns itself entirely with defining the set of
specifications that make up SIP itself. Excluded from this list are
requirements, architectures, registry definitions, non-normative
frameworks, and processes. Best Current Practices are included when
they are effectively standard mechanisms for accomplishing a task.
Spencer: "effectively standard mechanisms" seems slightly off. Perhaps "when
they normatively define mechanisms for accomplishing a task"?
Also excluded are definitions of MIME objects that are used by SIP,
such as the Authenticated Identity Body (AIB) [16] and various XML
documents and extensions used by SIP. Though they are used by SIP,
they are not extensions to SIP. [[OPEN ISSUE: Is this arbitrary?
Maybe they should be included if they are specific to SIP.]]
Spencer: You're the one who is doing the work, but if it's not too much
work, I would like to see the MIME objects included - they are very
important, and they are at least as obscure as other stuff you've included.
The SIP change process [17] defines two types of extensions to SIP.
These are normal extensions and the so-called P-headers, which are
meant to be used in areas of limited applicability. P-headers cannot
Spencer: probably spell out P-headers here? Not that we know what "P" stands
for. Stealing text from RFC 3427: "... the so-called "preliminary",
"private", or "proprietary" headers, or P-headers, which begin with "P-",
and which are meant to be used in areas of limited applicability".
be defined in the standards track. For the most part, P-headers are
not included in the listing here, with the exception of those which
have seen general usage despite their P-header status.
3. Core SIP Specifications
RFC XXXX: Enhancements for Authenticated Identity Management in SIP
(S) RFC XXXX [28] defines a mechanism for providing a
cryptographically verifiable identity of the calling party in a
SIP request. Also known as "SIP Identity", this mechanism
provides an alternative to RFC 3325. It has seen little
deployment so far, but its importance as a key construct for
Spencer: NO idea what "almost also" is doing in this sentence, but assume
that you meant to say something here. Just flagging for you.
almost also anti-spam techniques makes it a core part of the SIP
specifications.
RFC XXXX: Managing Client Initiated Connections through SIP (S) RFC
XXXX [30], also known as SIP outbound, defines important changes
to the SIP registration mechanism which enable delivery of SIP
messages towards a UA when it is behind a NAT. This specification
is the cornerstone of the SIP NAT traversal strategy.
Spencer: this is not news to you (of all people), but there are a lot of NAT
traversal-related specifications - maybe enough to justify its own section?
At the very least, having "the cornerstone" listed last seems less
helpful...
5. General Purpose Infrastructure Extensions
RFC 2976: The INFO Method (S) RFC 2976 [39] was defined as an
extension to RFC 2543. It defines a method, INFO, used to
transport mid-dialog information that has no impact on SIP itself.
Its driving application was the transport of PSTN related
information when using SIP between a pair of gateways. Though
originally conceived for broader use, it only found standardized
usage with SIP-T [33]. It has been used to support numerous
proprietary and non-interoperable extensions due to its poorly
defined scope.
Spencer: I know that draft-rosenberg-sip-info-harmful didn't advance (even
though I wish it had), but am wondering if the guidance here could be
stronger. Unless people really disagree with "However, since its initial
usage for that purpose, INFO has seen widespread abuse as a means for
introducing non-standard and non-interoperable extensions to SIP. For this
reason, we now believe INFO should be considered harmful, and therefore,
deprecated in its current form", maybe this text (from the draft) could be
inserted here.
RFC 3326: The Reason header field for SIP (S) RFC 3326 [40] defines
the Reason header field. It is used in requests, such as BYE, to
indicate the reason that the request is being sent.
RFC 3840: Indicating User Agent Capabilities in SIP (S) RFC 3840
defines a mechanism for carrying capability information about a
user agent in REGISTER requests and in dialog-forming requests
like INVITE. It has found use with conferencing (the isfocus
parameter declares that a user agent is a conference server) and
with applications like push-to-talk.
Spencer: is there a useful reference for "push-to-talk"?
10. Operations and Management
Spencer: You have been pointing to specifications (this is good). I'm
wondering if there are a couple of places (Operations and Emergency Services
being two) where it is worth pointing to entire working groups developing
specifications. If the answer is "no, because RFCs live forever and WGs
don't", that's fine. Maybe this could be a general observation, much earlier
in the document.
13. Security Mechanisms
RFC 3329: Security Mechanism Agreement for SIP (S) RFC 3329 [80]
defines a mechanism to prevent bid-down attacks in conjunction
with SIP authentication. The mechanism has seen very limited
deployment. It was defined as part of the 3gpp IMS specification
Spencer: Same comment as "push to talk" - is there a helpful pointer to
"IMS", which hasn't been spelled out yet, to use as a reference?
suite, and is needed only when there are a multiplicity of
security mechanisms deployed at a particular server. In practice,
this has not been the case.
RFC XXXX: End-to-Middle Security in SIP (S) RFC XXXX [81] defines
mechanisms for encrypting content from user agents to specific
Spencer: maybe you guys aren't used to working with people who are easily
confused :-) but s/content/SIP message bodies/. Also - the I thought the
draft last-called in December included integrity protection, not just
encryption? Perhaps worth mentioning integrity protection as well.
network intermediaries.
14. Instant Messaging and Presence
SIP provides extensions for instant messaging and presence.
Spencer: I wish there was a little more definition of "presence" than
appears here, and probably earlier in the document ("presence" has a pretty
specific meaning here).
RFC 3428: SIP Extension for Instant Messaging RFC 3428 [82] defines
the MESSAGE method, used for sending a page mode instant message.
Spencer: "page mode" seems pretty obscure for the intended reader base.
Perhaps "sending an instant message without setting up a session"?
15. Emergency Services
Spencer: see previous note on possibly pointing out the existence of entire
working groups.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip