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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 05 Mar 2007 11:09:19 -0500

This note is almost a yaer old; I would have missed it completely if 
Spencer hadn't reminded me of it recently. I did an update of the guide, 
and wanted to include Spencer's comments that were still relevant.

Responses inline.

Spencer Dawkins wrote:

> 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

removed and apostrophed.

> 
> 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.

this is noted in the Scope section

> 
>   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]"...

This was added as reference 42 and exists as a tag for all such jokes.

> 
>   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.

I believe this was fixed.

> 
>   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".

Sure. Added "deployers".

> 
> 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:

this is gone so a split is not needed anymore.

> 
> Spencer: It's definitely worth a section header that says "Related 
> Specifications" above these documents.

as above

> 
> 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."

no longer an issue since 3550 is gone

> 
> 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.

this particular reference was removed when RFC 3550 disappeared. 
Unfortunately, this left us with no jokes about 42! Impossible for a 
document on hitchhikers guide. I added one (with a refernece to the book).

> 
>  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/

TRIP is gone.

> 
>   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?

families are gone.

> 
>   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"?

ok

> 
>   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.

they are now 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".

done

> 
>   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.

removed also

> 
>      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...

all of them are here, though as you say not in there own section. Not a 
a bad idea to have a section on nat traversal which repeats the relevant 
ones. Added.

> 
> 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.

That is not appropriate for this specification. I put about as much of 
info-harmful in here as I think does apply to an informational summary doc.

> 
>   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"?

not at ietf.

> 
> 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.

The scope of the document is clear - it points to SIP extensions, SDP 
extensions and MIME bodies. I am aggressively protecting that scope 
boundary.

> 
> 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?

24.229. Added 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.

added and changed

> 
>      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).

These days I think its reasonably understood in communications circles.

> 
>   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"?

done

> 
> 15.  Emergency Services
> 
> Spencer: see previous note on possibly pointing out the existence of 
> entire working groups.

same response - not in scope.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip