Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)
draft-ietf-sip-guidelines-09

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

-----

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

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.

There's some unusual indentation in sections 3.2 and 4.4.

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.