ietf
[Top] [All Lists]

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

2017-06-23 10:29:48
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 
<christer(_dot_)holmberg(_at_)ericsson(_dot_)com> Date: 23/06/2017  12:45  
(GMT+00:00) To: Elwyn Davies <elwynd(_at_)dial(_dot_)pipex(_dot_)com>, 
gen-art(_at_)ietf(_dot_)org Cc: 
draft-ietf-sipcore-content-id(_dot_)all(_at_)ietf(_dot_)org, 
sipcore(_at_)ietf(_dot_)org, ietf(_at_)ietf(_dot_)org 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

<Prev in Thread] Current Thread [Next in Thread>