Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)
RFC 4485

Note: This ballot was opened for revision 09 and is now closed.

(Harald Alvestrand) No Objection

Comment (2005-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed by Spencer Dawkins, Gen-ART

Full review in document comments; there are some issues that should be addressed (in particular, the comment about "compact form" headers) if the document is respun for other reasons.

But no show-stoppers.

(Margaret Cullen) No Objection

(Ted Hardie) No Objection

Comment (2005-02-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
In Section 3:

   First, the problem SHOULD fit into the general purvey of SIP's
   solution space. 

I believe they mean "purview".

In 4.1, the document says:

   Yet another type of extension is that which defines new body types to
   be carried in SIP messages.  According to the SIP specification,
   bodies must be understood in order to process a request.  As such,
   the interoperability issues are similar to new methods.  However, the
   Content-Disposition header field has been defined to allow a client
   or server to indicate that the message body is optional [2].  Usage
   of optional bodies, as opposed to mandatory ones, is RECOMMENDED
   wherever possible.

It might be valuable to highlight "by whom" here, since the text above
notes that proxies should not be required to understand new body types.
I believe that the intent is to say:  when the design allows, use optional
bodies so that end points are not needlessly prevented from participating
in the SIP-arranged session.  This is fine, but a little different from the
world as seen by a proxy.

In section 4.2, it might be useful to highlight the difference between the
security provided by SIP (for its signalling) vs. the security provided by
the protocol being set up.  Conflating the two seems to be a common
problem in this kind of extension, and it might be valuable to capture it here.

In section 4.4, the draft says:

   Extensions which have header fields containing URIs SHOULD allow any
   URI, not just SIP URIs.

It might be valuable to say instead that extensions which have header fields containing
URIs should be explicit about the supported URI schemes, and it should not be
assumed that only SIP URIs are permitted.  There are valid reasons to restrict URI
schemes, and though the SHOULD allows that restriction, it seems to plump
pretty hard for unlimited extensions.  That may be more rope than we want to
hand out.

(Scott Hollenbeck) No Objection

Comment (2005-02-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
There's some unusual indentation in sections 3.2 and 4.4.

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) (was Discuss, Yes) No Objection

Comment (2005-02-03)
No email
send info
  Compression of SIP messages SHOULD be
  handled at lower layers, for example, using IP payload compression
  [16] or signalling compression [18]

Reference 16 should be to RFC 3173, rather than 2393, which is


Under 4.7, it's good that the discussion of the overview section is there.  Could you
add guidance that authors should be sure to expand even the most familiar terms such
as UA on first occurrence, and treat the overview section as providing context to non-SIP

(Bert Wijnen) No Objection