Re: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-data-only-ea-21: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 2/23/2020 2:05 PM, Barry Leiba via Datatracker wrote:
> — Section 5.2 —
>
>        ErrorValue       =  error-code
>                                 *(SEMI error-params)
> …
>     The ErrorValue contains a 3-digit error code indicating what was
>     wrong with the alert in the request.  This error code has a
>     corresponding quoted error text string that is human readable.  The
>     text string is OPTIONAL, but RECOMMENDED for human readability,
> …
>     Similar to how RFC
>     3261 specifies, there MUST NOT be more than one string per error
>     code.
>
> Two things about this:
>
> 1. The ABNF makes the text string optional only by allowing zero or more of
> them (so zero is allowed).


This is true. Is this a problem? A production like [*(SEMI 
error-params)] seems redundant.


> 2. The ABNF allows multiple text strings, but the text says that there MUST NOT
> be more than one.
>
> So, shouldn’t the ABNF be this (and if not, why not)?:
>
> NEW
>        ErrorValue       =  error-code [SEMI error-params]
> END


The production is like it is in the current document because 
"error-params" is not _just_ the error code text. It is defined as 
"error-code-text / generic-param", which is a common way to define SIP 
header fields so that future extensions fit the ABNF in a 
backwards-compatible way (by matching "generic-param").

If, for some reason, you wanted the ABNF to explicitly reflect the prose 
you're citing, it would end up looking like:

Errorvalue = *(SEMI generic-param) [SEMI error-code-text] *(SEMI 
generic-param)

But that's really unnecessarily prolix, and it doesn't even technically 
provide any enforcement, since "error-code-text" also matches 
"generic-param".

What it comes down to is that this is one of the cases, common in SIP, 
where the decision was made to make the ABNF easy-to-read, and to 
provide enforcement of any semantic restrictions as part of the 
normative language rather than attempting to use syntax to do so.

/a