RE: Genart last call review of draft-ietf-sipcore-content-id-06

[Christer Holmberg <[e-mail]>]

Hi,

>Looks like we are clear on all this, except that:
>1.  I would suggest making it explicit that you can add a Content-ID header even to a
> message with a multipart message-body to avoid any confusion.  I am not sure that it
> makes any sense but I guess it wouldn't do any harm.

I suggest adding the following note to the end of section 3.3.


“NOTE: The message body identified by the Content-ID header field can be a

non-multipart message-body or a multipart message-body.”

>2.  If a message of a kind that can legitimately have a Content-ID arrives with a
>
>Content-ID (or indeed any Content-*) header but no message-body, presumably one would
> send a 400 error with a suitable reason phrase.  I think it would be worth being explicit about this.

Well, there is actually a use-case for a Content-Type value (I did not check the other header fields) but no message-body.

Section 20.15 of RFC 3261 says:


        “If the body is empty, and a Content-Type header field is present, it indicates that the body of the specific

        type has zero length (for example, an empty audio file).”

And, to echo Paul, I don’t see a reason to say something specific for the Content-* header fields. Normal SIP procedures should apply regarding receiving header fields with no meaning for a particular SIP message.

Regards,

Christer



-------- Original message --------
From: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Date: 23/06/2017 12:45 (GMT+00:00)
To: Elwyn Davies <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>, [e-mail]<mailto:[e-mail]>
Subject: RE: Genart last call review of draft-ietf-sipcore-content-id-06

Hi Elwyn,

Thank You for the review! Please see inline.

>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 aware of any current use-case, but I see no reason to forbid it. Perhaps someone will come up with a use-case in future.

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

The statement about global uniqueness is a bug, and will be fixed. The value only has to be unique within the message.

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

I see no reason to forbid it.

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

Normal RFC 3261 procedures apply. I don't think we want to copy/paste the generic header processing rules,

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

In the ABNF of RFC 3261, "message-header" contains the header fields defined in the RFC, plus "extension-header", which is used for new headers. I assume people think that is clear enough :)

Having said that, what you suggest is not necessarily a bad idea, but it is outside the scope of this draft.

>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

Looks ok. I will modify as suggested.

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

Will be fixed as suggested.

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

I realized the first usage is in section 1.3, so I will expend it there.

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

Will be fixed as suggested.

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

Will be fixed as suggested.

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

Will be fixed as suggested.

Regards,

Christer