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

From: Elwyn Davies <[email-masked]>
Date: Fri, 23 Jun 2017 15:53:00 +0100

Hi, Christer.
Thanks for the quick response.
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. 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.
Cheers,Elwyn

Sent from Samsung tablet.
-------- Original message --------From: Christer Holmberg <[email-masked]> Date: 23/06/2017  12:45  (GMT+00:00) To: Elwyn Davies <[email-masked]>, [email-masked] Cc: [email-masked], [email-masked], [email-masked] 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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Jun 2017 17:36:19 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: 23/06/2017 12:45 (GMT+00:00)
To: Elwyn Davies <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
Subject: RE: Genart last call review of draft-ietf-sipcore-content-id-06

Hi Elwyn,

Regards,

Christer