Last Call Review of draft-ietf-sipcore-content-id-06
review-ietf-sipcore-content-id-06-genart-lc-davies-2017-06-22-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sipcore-content-id-06
Reviewer: Elwyn Davies
Review Date: 2017-06-22
IETF LC End Date: 2017-06-27
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready with nits.  There are a couple of minor issues related to the procedures
after inappropriate usage of the new header.

Major issues:
None

Minor issues:
s3.4.1, last para: In line with the last sentence of Section 3.2, the
Content-ID URL only needs to be unique within the SIP message where it occurs.
 I assume it does not make sense to have a Content-ID header combined with a
mutipart message-body (this isn't stated - maybe it should be); I am not
sufficiently knowledgeable in this area of SIP to know if there could be
content-id URLs in other headers if there is a Content-ID header in the
message.  Thus either the statement about global uniqueness is irrelevant (as
there is only one) and can be removed or it should be made consistent with s3.2
so that the Content URLs are unique within the message. Global uniqueness is
neither possible or required.

s3.4.1, para 1: Following on from the previous comment: Is a UA allowed to add
a Content-ID header to a message with a multipart message-body?

s3.4.1: What should a UA do if it receives a message with a Content-ID header
when the message is not allowed to contain one?  Is there some generic error
procedure that should be referenced?

s6.1: I started looking for specification that told me that items added to the
SIP header fields registry effectively extend the definition of the
message-header production in Section 25.1of RFC 3261.  Bit obvious perhaps, but
it would be nice if it had been said somewhere!  Time for an Erratum perhaps?

Nits/editorial comments:
Abstract:  I would suggest adding a sentence that clarifies what the update of
RFC 5621 is modifying: OLD: The document also updates RFC 5621, to enable a
Content-ID URL to reference a complete message-body and metadata provided by
some additional SIP header fields. NEW: The document also updates RFC 5621,
which only allows a Content-ID URL to reference a body-part that is part of a
multipart message-body.  This update enables a Content-ID URL to reference a
complete message-body and metadata provided by some additional SIP header
fields. END

s1.2, first bullet: s/for providing location/for providing location information/

s1.4.1: Need to expand UAC (User Agent Client) on first usage.

s1.4.1, para 1: s/can be e.g. of/can be, for example, of/

s3.4.1: Need to expand UA (User Agent) on first usage (in section title).

s4, NEW text: s/allow creating/allow the creation of/