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 protected]<mailto:[email protected]>>
Date: 23/06/2017 12:45 (GMT+00:00)
To: Elwyn Davies <[email protected]<mailto:[email protected]>>,
[email protected]<mailto:[email protected]>
Cc:
[email protected]<mailto:[email protected]>,
[email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
