Subject: [Sip] My notes on draft-rosenberg-sip-hitchhikers-guide-00

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 11 Apr 2006 15:28:09 -0500

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip