Subject: [sipcore] Discussion on Table 2 relative to RFC3329 errata (2170)

From: Dean Willis <[email-masked]>
Date: Fri, 23 Apr 2010 13:59:40 -0500

On Apr 23, 2010, at 8:27 AM, RFC Errata System wrote:
>
>
> Original Text
> -------------
> The second INVITE (4) and the ACK (8) contain a Security-Verify
>   header field that mirrors the Security-Server header field received
>   in the 421.
>
> Corrected Text
> --------------
> The second INVITE (4) contains a Security-Verify
>   header field that mirrors the Security-Server header field received
>   in the 421.
>
> Notes
> -----
> RFC 3329 Section 2.6, Table 1: Summary of Header Usage. indicates  
> that Security-Client, Security-Server, Security-Verify are "Not  
> applicable" to the SIP ACK request.
>
> RFC 3261 says "Not applicable" means that the header field MUST NOT  
> be present in a request.  If one is placed in a request by mistake,  
> it MUST be ignored by the UAS receiving the request."
>

We've been discussing the role of Table 2. Here, said table (as  
modified by the RFC in question) is being viewed as authoritative on  
the inclusion of Security-Verify in the examples used by that RFC.

Clearly, we have a mismatch between the specification and its table 2  
modification.

Is Table 2 here helping us catch spec errors, or is it just confusing  
the specification writer?

--
dean