Re: [sipcore] SIP and SIPCORE errata

[Paul Kyzivat <[e-mail]>]

Francesca,

I examined each of these. I've included my opinions inline below.

On 11/9/23 5:22 PM, Francesca Palombini wrote:
> Apologies for the double mail, I didn’t consider the “sipping” working 
> group. 4 additional errata added below, for a grand total of 21 (7.5% of 
> all current reported technical errata for ART).
> 
> Thanks!
> Francesca
> 
> *From: *Francesca Palombini <[e-mail]>
> *Date: *Thursday, 9 November 2023 at 23:02
> *To: *[e-mail] <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *SIP and SIPCORE errata
> 
> Hello working group!
> 
> In my effort to clean up the erratas for art documents, I have 
> identified 17of them for sip and sipcore (see below), and I believe this 
> working group should take a look at them. By the way, the sip 
> specification is updated by a number of RFCs, so it might be possible 
> that some of these are already taken care of, but even so they shouldn’t 
> be left “open” (in case they are already fixed by another doc, the right 
> thing to do is mark them “Hold for doc update”). I also have tried to 
> find previous discussion in the mailarchive, when archived.
> 
> As a reminder, this gives guidelines on how errata should be handled, 
> and what I base my evaluation on: 
> https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ <https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/>
> 
> Please, take a look and let me know if you agree. Thank you!
> Francesca
> 
> ---
> 
> This is the list of erratas: 
> https://www.rfc-editor.org/errata_search.php?rec_status=2&errata_type=2&wg_acronym=sip&presentation=table <https://www.rfc-editor.org/errata_search.php?rec_status=2&errata_type=2&wg_acronym=sip&presentation=table> and https://www.rfc-editor.org/errata_search.php?rec_status=2&errata_type=2&wg_acronym=sipcore&presentation=table <https://www.rfc-editor.org/errata_search.php?rec_status=2&errata_type=2&wg_acronym=sipcore&presentation=table>and https://www.rfc-editor.org/errata_search.php?rec_status=2&errata_type=2&wg_acronym=sipping&presentation=table <https://www.rfc-editor.org/errata_search.php?rec_status=2&errata_type=2&wg_acronym=sipping&presentation=table>
> 
> https://www.rfc-editor.org/errata/eid4275 
> <https://www.rfc-editor.org/errata/eid4275> --> my first thought is to 
> reject, as this seems it is not an error but a decision of the working 
> group, and changing the behaviour should be done in a consensus 
> document, but please check.

I agree on rejecting. I don't understand the proposers logic, but the 
caller's UA need not ever send a BYE if the callee's UA does.

> https://www.rfc-editor.org/errata/eid4553 
> <https://www.rfc-editor.org/errata/eid4553> --> I think this should be 
> "Hold for document update"; it seems as this is in line with the 
> original intent of the document, but the change of SHOULD to MUST make 
> me pause and reticent to just verify this. I believe this was also 
> expressed in the mailing list (thread starting here: 
> https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35zNp4/ <https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35zNp4/>)

As 3261 is written, if the handling parameter is missing and the 
recipient doesn't understand the content type, then because of the 
SHOULD it might treat the handling as required and fail the request, or 
might treat it as optional and simply ignore the body. The errata 
removes that ambiguity.

The other change made by the errata ("or if the Content-Disposition 
header field is missing") is simply a clarification and doesn't really 
change anything.

Given how old this errata is, verifying it now is unlikely to change the 
behavior of any implementations. So it isn't urgent.

So I agree that "hold for document update" is appropriate.

> https://www.rfc-editor.org/errata/eid5653 
> <https://www.rfc-editor.org/errata/eid5653> --> The way this is written 
> makes me hard to evaluate, so I would "reject". I would suggest the 
> submitter to either resubmit with a correct OLD/NEW text, or even better 
> to get feedback from the mailing list before doing so.

I defer to Robert on timer questions.

> https://www.rfc-editor.org/errata/eid6645 
> <https://www.rfc-editor.org/errata/eid6645> --> I believe this should be 
> "verified" as editorial. Also, the same errata should be submitted for 
> Section 23.4.3.

Agree

> https://www.rfc-editor.org/errata/eid6793 
> <https://www.rfc-editor.org/errata/eid6793> --> I believe this should be 
> rejected

Agree

> https://www.rfc-editor.org/errata/eid7529 
> <https://www.rfc-editor.org/errata/eid7529> --> Without diving too deep 
> into the updates to RFC 2616 and HTTP/1.1, this seems as it should be 
> verified, please check.

Without checking I will trust the assertion that the 3261 syntax here 
isn't exactly equivalent to the RFC 2616 syntax. But the proper fix now 
is not to change the sip syntax. Rather the reference to RFC 2616 should 
be removed. I don't think anybody is repurposing an http parser to parse 
this.

> https://www.rfc-editor.org/errata/eid4605 
> <https://www.rfc-editor.org/errata/eid4605> --> Given the amount of 
> changes in this errata, I believe this is going beyond what erratas are 
> for. I am not sure this is fixing an error. These statements went 
> through IETF and IESG review as part of the original document. Changing 
> them so would be a material change to the contents of the document 
> without first gaining consensus from the appropriate parties. The errata 
> process cannot be used to make this kind of material change.

I'm too lazy to do the diffs necessary to see exactly what the proposed 
changes are. I'm inclined to reject it and suggest that the author may 
resubmit it with more explanation of the changes. (Christer, are you 
listening?)

> https://www.rfc-editor.org/errata/eid5184 
> <https://www.rfc-editor.org/errata/eid5184> --> This thread: 
> https://mailarchive.ietf.org/arch/msg/sipcore/QewAnXtrf-Y4zqUh2CML6FaQ6Yw/ <https://mailarchive.ietf.org/arch/msg/sipcore/QewAnXtrf-Y4zqUh2CML6FaQ6Yw/> seems to suggest that rejecting this is the right thing.

Agree

> https://www.rfc-editor.org/errata/eid4652 
> <https://www.rfc-editor.org/errata/eid4652> --> Hold for document 
> update, or reject. This brings up a valid point, but this sort of 
> technical change goes beyond what errata can do. (note that the same 
> errata 4651 was hold for document update, but I would lean more on reject)

IMO it is fine for it to be held for document update.

I don't see why it outside the scope of an errata.

> https://www.rfc-editor.org/errata/eid4650 
> <https://www.rfc-editor.org/errata/eid4650> --> Same as above: Hold for 
> document update, or reject. This brings up a valid point, but this sort 
> of technical change goes beyond what errata can do.

IMO it is fine for it to be held for document update.

I don't see why it outside the scope of an errata.

> https://www.rfc-editor.org/errata/eid4744 
> <https://www.rfc-editor.org/errata/eid4744> --> Reject: This one too 
> goes beyond what the errata is for.

I agree with rejecting this. The stated problem is at best incomplete, 
because a session timer can be established without any participation of 
the UAC. And there is no such thing as "another" session timer - there 
is at most one session timer per session. Every INVITE and UPDATE either 
establishes a session timer or results in there being none.

There is a race condition that I recall being discussed at some point. 
It is when UPDATE is used in an early dialog after a session timer 
negotiation was started in the original INVITE. I don't recall what the 
conclusion of that was. Does somebody recall?

So there is something that ought to be clarified, but this errata is 
neither a good statement of it nor a solution to it.

> https://www.rfc-editor.org/errata/eid4886 
> <https://www.rfc-editor.org/errata/eid4886> --> Verified with type editorial

Agree

> https://www.rfc-editor.org/errata/eid5014 
> <https://www.rfc-editor.org/errata/eid5014> --> after looking in the 
> mailarchive, this: 
> https://mailarchive.ietf.org/arch/msg/sipcore/C3eDkbfibtiyug-M6aOuf9fTvtE/ <https://mailarchive.ietf.org/arch/msg/sipcore/C3eDkbfibtiyug-M6aOuf9fTvtE/> convinced me this one should be rejected.

No opinion

> https://www.rfc-editor.org/errata/eid5442 
> <https://www.rfc-editor.org/errata/eid5442> --> I believe this should be 
> rejected.

No opinion

> https://www.rfc-editor.org/errata/eid5937 
> <https://www.rfc-editor.org/errata/eid5937> --> This errata should be 
> removed as the submitter wanted to withdraw it: 
> https://mailarchive.ietf.org/arch/msg/sipcore/6YU8Ax-Yaz6YtnALBTSj_Rkv_Ks/ <https://mailarchive.ietf.org/arch/msg/sipcore/6YU8Ax-Yaz6YtnALBTSj_Rkv_Ks/> so it can be rejected or even better deleted by the RFC editor.

Whatever the proper way is to remove it

> https://www.rfc-editor.org/errata/eid7136 
> <https://www.rfc-editor.org/errata/eid7136> --> At first look I would 
> say this should be "verified" and editorial, but please check.

Agree

> https://www.rfc-editor.org/errata/eid6586 
> <https://www.rfc-editor.org/errata/eid6586> --> Verified, but technical 
> or editorial, I am not sure (though maybe editorial, if this can be 
> considered an example)

Maybe I'm confused, but ISTM the rfc is right and the errata is wrong.

> https://www.rfc-editor.org/errata/eid5294 
> <https://www.rfc-editor.org/errata/eid5294> --> I believe this should be 
> verified, as editorial.

No opinion

> https://www.rfc-editor.org/errata/eid6242 
> <https://www.rfc-editor.org/errata/eid6242> --> Probably also verified 
> as editorial.

Agree

> https://www.rfc-editor.org/errata/eid6984 
> <https://www.rfc-editor.org/errata/eid6984> --> I would reject this 
> based on the fact that the report is not correctly formatted with 
> OLD/NEW text. I don't really get the submitter point, so maybe someone 
> else can suggest if this should be resubmitted with proper form.

No opinion

> https://www.rfc-editor.org/errata/eid4237 
> <https://www.rfc-editor.org/errata/eid4237> --> without the context, I 
> am not sure about this. Any thoughts?

No opinion

	Thanks,
	Paul