errata logo graphic

Found 19 records.

Status: Verified (6)

RFC5322, "Internet Message Format", October 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1905

Status: Verified
Type: Technical

Reported By: Wolf Lammen
Date Reported: 2009-10-09
Verifier Name: Pete Resnick
Date Verified: 2011-06-11

Section 4.1 says:

   obs-unstruct    =   *((*LF *CR *(obs-utext *LF *CR)) / FWS)

It should say:

   obs-unstruct    =   *( (*CR 1*(obs-utext / FWS)) / 1*LF ) *CR

Notes:

It looks to me, as if the rule for obs-unstruct matches any US_ASCII character sequence, and is, hence, either overly complicated, or simply wrong. For example: CR LF 'A' is matched by the original rule (loop matches CR first, then LF 'A'). If I understand the accompaying text right, the intention was to allow for reversed sequences LF CR, as well as bare CR and LF sequences, but strictly forbid any occurrence of CR LF (in that order). This would be expressed by my rule, that basically states that any sequence of CR either is at the end, or is followed by a non-LF, or an FWS

[Alexey: removed unchanged ABNF rules, corrected an obvious error in the description of the change.]


Errata ID: 1908

Status: Verified
Type: Technical

Reported By: Wolf Lammen
Date Reported: 2009-10-11
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24

Section 4.2 says:

   In the obsolete syntax, any amount of folding white space MAY be
   inserted where the obs-FWS rule is allowed.  This creates the
   possibility of having two consecutive "folds" in a line, and
   therefore the possibility that a line which makes up a folded header
   field could be composed entirely of white space.

   obs-FWS         =   1*WSP *(CRLF 1*WSP)

It should say:

   In the obsolete syntax, any amount of folding white space MAY be
   inserted where the obs-FWS rule is allowed.  This creates the
   possibility of having two consecutive "folds" in a line, and
   therefore the possibility that a line which makes up a folded header
   field could be composed entirely of white space.

   obs-FWS         =   1*([CRLF] WSP)

Notes:

If I understand the relevant portions of RFC 822 right (notably section 3.1.1
["The general rule is that wherever there may be linear-white-space...
a CRLF followed by ... LWSP-char(s) may instead be inserted"], along with
section 3.1.4, section 3.3), it is permitted to extend a phrase
atom SPACE atom
by inserting linear-white-space (CRLF SPACE CRLF SPACE) instead, yielding:
atom CRLF SPACE CRLF SPACE atom
However, this is not recognized by the rules of RFC 5322, because the new
syntax forbids consecutive foldings, whereas obs-FWS requires a leading
white-space character at the beginning.


Errata ID: 3979

Status: Verified
Type: Technical

Reported By: Peter Occil
Date Reported: 2014-04-30
Verifier Name: Pete Resnick
Date Verified: 2014-04-30

Section 3.6.7; 4.5.7 says:

received        =   "Received:" *received-token ";" date-time CRLF

obs-received    =   "Received" *WSP ":" *received-token CRLF

It should say:

received        =   "Received:" [1*received-token / CFWS]
                      ";" date-time CRLF

obs-received    =   "Received" *WSP ":" [1*received-token / CFWS] CRLF

Notes:

"The 'Received:' field contains a (possibly empty) list of tokens followed by a semicolon and a date-time specification." As it was originally written, though, whitespace and comments are disallowed right after the colon if the list of tokens is empty: for example, the header field "Received: ; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (with a space after the first colon) would be invalid according to the current spec; only "Received:; Wed, 30 Apr 2014 00:00:00 -0000\r\n" (without a space) would be.

Verifier note: The erratum is clearly correct. There are other possible ABNF solutions, but the one above is sufficient to fix the problem.


Errata ID: 1766

Status: Verified
Type: Editorial

Reported By: Nick Levinson
Date Reported: 2009-04-16
Verifier Name: Alexey Melnikov
Date Verified: 2010-03-24

Section 3.4.1 says:

If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or "." surrounded by atext characters), then the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used.

It should say:

If the string can be represented as a dot-atom (that is, it contains no characters other than atext characters or one or more of "." surrounded by atext characters), then the dot-atom form SHOULD be used and the quoted-string form SHOULD NOT be used.

Notes:

Based on sec. 3.2.3 ("dot-atom = [CFWS] dot-atom-text [CFWS]" (brackets so in original) & "dot-atom-text = 1*atext *('.' 1*atext)") and on appx. A.1.2 (the example "john.q.public@example.com").


Errata ID: 2515

Status: Verified
Type: Editorial

Reported By: Michael Rushton
Date Reported: 2010-09-10
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section Appendix A.5 says:

From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>

It should say:

From: Pete(A nice \) chap) <pete@silly.test(his host)>

Notes:

Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."


Errata ID: 2579

Status: Verified
Type: Editorial

Reported By: Dominic Sayers
Date Reported: 2010-10-18
Verifier Name: Pete Resnick
Date Verified: 2011-05-16

Section Appendix A.5 says:

   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

It should say:

   To:A Group(Some people)
        :Chris Jones <c@public.example(Chris's host.)>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

Notes:

Section 3.4.1: "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."


Status: Held for Document Update (5)

RFC5322, "Internet Message Format", October 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 1906

Status: Held for Document Update
Type: Technical

Reported By: Wolf Lammen
Date Reported: 2009-10-10
Held for Document Update by: Pete Resnick
Date Held: 2010-04-02

Section 4.1 says:

   obs-body        =   *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)

It should say:

   obs-body        =   *(%d0-127)

Notes:

The regular expression for obs-body is overly complex and can be simplified as suggested. Alternatively, one could use
*(d0 /text / LF / CR)
should the difference to 'text' be emphazised.

[Alexey: I've edited this to only show 1 issue per erratum.]


Errata ID: 2950

Status: Held for Document Update
Type: Technical

Reported By: Antonio Regidor GarcĂ­a
Date Reported: 2011-08-30
Held for Document Update by: Pete Resnick

Section 3.6 says:

   fields          =   *(trace
                         *optional-field /
                         *(resent-date /
                          resent-from /
                          resent-sender /
                          resent-to /
                          resent-cc /
                          resent-bcc /
                          resent-msg-id))
                       *(orig-date /
                       from /
                       sender /
                       reply-to /
                       to /
                       cc /
                       bcc /
                       message-id /
                       in-reply-to /
                       references /
                       subject /
                       comments /
                       keywords /
                       optional-field)

It should say:

   fields          =   *(trace
                         *optional-field /
                         1*(resent-date /
                           resent-from /
                           resent-sender /
                           resent-to /
                           resent-cc /
                           resent-bcc /
                           resent-msg-id))
                       *(orig-date /
                       from /
                       sender /
                       reply-to /
                       to /
                       cc /
                       bcc /
                       message-id /
                       in-reply-to /
                       references /
                       subject /
                       comments /
                       keywords /
                       optional-field)

Notes:

The original version causes an infinite loop (matching an infinite list of empty strings).


Errata ID: 3135

Status: Held for Document Update
Type: Technical

Reported By: Ashley Willis
Date Reported: 2012-02-25
Held for Document Update by: Pete Resnick

Section 3.2.4 says:

   quoted-string   =   [CFWS]
                       DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                       [CFWS]

It should say:

   quoted-string   =   [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [CFWS]

Notes:

The text following this definition states that a "quoted-string is identical to atom, semantically." "Semantically, neither the optional CFWS outside of the quote characters nor the quote characters themselves are part of the quoted-string; the quoted-string is what is contained between the two quote characters."

The published definition allows, for example, an angle-addr of <""@ietf.org> which is equivalent to <@ietf.org>, hence invalid. The corrected definition ensures that at a minimum there is one FWS or qcontent between each DQUOTE.

Currently allowed yet invalid: <""@ietf.org>, <foo.""@ietf.org>, <"".bar@ietf.org>, and <foo."".bar@ietf.org>.

As a quoted-string must be bound by the ends of the local-part or by a dot, there is no change in regard to the currently invalid addresses such as <foo""@ietf.org>, <""bar@ietf.org>, and <foo""bar@ietf.org>.


Errata ID: 2726

Status: Held for Document Update
Type: Editorial

Reported By: Tony Finch
Date Reported: 2011-02-21
Held for Document Update by: Pete Resnick

Section 3.3 says:

   The zone specifies the offset from Coordinated Universal Time (UTC,
   formerly referred to as "Greenwich Mean Time") that the date and
   time-of-day represent.  The "+" or "-" indicates whether the time-of-
   day is ahead of (i.e., east of) or behind (i.e., west of) Universal
   Time.  The first two digits indicate the number of hours difference
   from Universal Time, and the last two digits indicate the number of
   additional minutes difference from Universal Time.  (Hence, +hhmm
   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
   Universal Time.  Though "-0000" also indicates Universal Time, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than Universal Time and that the date-time
   contains no information about the local time zone.

It should say:

   The zone specifies the offset from Coordinated Universal Time (UTC) 
   that the date and time-of-day represent.
   The "+" or "-" indicates whether the time-of-
   day is ahead of (i.e., east of) or behind (i.e., west of) UTC.
   The first two digits indicate the number of hours difference
   from UTC, and the last two digits indicate the number of
   additional minutes difference from UTC.  (Hence, +hhmm
   means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm)
   minutes).  The form "+0000" SHOULD be used to indicate a time zone at
   UTC.  Though "-0000" also indicates UTC, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than UTC and that the date-time
   contains no information about the local time zone.

Notes:

It is not correct to say that UTC was formerly referred to as GMT. I think this was an editorial mistake: RFC 822 did not use the term UTC and said "Universal Time (formerly called Greenwich Mean Time)" which is reasonably correct for UT without a suffix.

For the purposes of RFC 5322 and for consistency with RFC 3339 and ISO 8601 I think it is best to refer to UTC throughout - though see the next erratum for notes on the obsolete syntax.


Errata ID: 3048

Status: Held for Document Update
Type: Editorial

Reported By: Pan GaoYong
Date Reported: 2011-12-08
Held for Document Update by: Pete Resnick
Date Held: 2011-12-29

Section 3.6.6. Rese says:

   When resent fields are used, the "Resent-From:" and "Resent-Date:"
   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.

It should say:

   When resent fields are used, the "Resent-From:" and "Resent-Date:"
   fields MUST be set.  The "Resent-Message-ID:" field SHOULD be set.

Notes:

[Verifier note: The original report only noted the second use of the word "sent". I have updated to include both. I have marked as "Hold" because (a) I believe the meaning is clear in the current and (b) it is not obvious that "set" is the correct word here; perhaps "used" is better. Left for an editing pass when this moves to Standard.]


Status: Rejected (8)

RFC5322, "Internet Message Format", October 2008

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 2104

Status: Rejected
Type: Technical

Reported By: Wolf Lammen
Date Reported: 2010-04-02
Rejected by: Pete Resnick
Date Rejected: 2011-06-11

Section 4.1 says:

obs-unstruct    =   *((*LF *CR *(obs-utext *LF *CR)) / FWS)

It should say:

obs-unstruct    =   *(*LF *CR (obs-utext / FWS)) *LF *CR
                    ;The CR of a following CRLF MUST NOT be consumed.

Notes:

[I was notified, that errata report 1766 and 1908 has been verified, but apparently, report 1905 was left undecided. I am a bit concerned, because this report points to a true defect of RFC 5322, so, maybe, a clearer reasoning helps. This report is meant to replace my former posting 1905.]

The <obs-unstruct> rule covers field bodies of unstructured fields (as declared in section 2.2.1), that conform to obsoleted RFC 2822 or RFC 822. It is only to be used for downward compatibility when reading messages. It corresponds to <text> in RFC 822 and <obs-utext> in RFC 2822. In a conforming message, an unstructured field body is always followed by a field delimiting non-folding CRLF.

<obs-unstruct> is equivalent to *(d0-d127), so the CRLF delimiting the field is made part of the field body, as is the rest of the header section.

So my proposal refines the rule: Use any, possibly empty, sequence of ASCII characters, as long as it does not contain a CRLF outside of a folding white space.

There is a nuisance left: when applied possessively, the CR of the adjacent field delimiter CRLF is consumed as well. This cannot be overcome, no matter how you rewrite the rule, because the ABNF in RFC 5324 is not rich enough to express something like "consume all but one CR". A higher level construct like "obs-unstruct CRLF" must enforce a back-tracking step on the part of <obs-unstruct> in order to match. That is why I added the comment.
--VERIFIER NOTES--
Duplicate of erratum 1905, which I believe is correct as stated.


Errata ID: 2816

Status: Rejected
Type: Technical

Reported By: Nemo
Date Reported: 2011-05-27
Rejected by: Pete Resnick
Date Rejected: 2011-05-27

Section 3.6.2 says:

   from            =   "From:" mailbox-list CRLF

   sender          =   "Sender:" mailbox CRLF

   reply-to        =   "Reply-To:" address-list CRLF

It should say:

   from            =   "From:" mailbox-list CRLF

   sender          =   "Sender:" mailbox CRLF

   reply-to        =   "Reply-To:" mailbox-list CRLF

Notes:

The text in section 3.6.2 (and everywhere else Reply-To is mentioned) makes it clear that Reply-To is envisioned as referring to one or more mailboxes. But the following chain of productions:

address-list -> address -> group -> DQUOTE DQUOTE ":" ";"

...means that the following Reply-To header would be permitted by the spec:

Reply-To: "" : ;

This header has no mailbox in it at all. So either the reply-to production rule is wrong (and should be a mailbox-list instead of an address-list), or the spec needs to explain what the semantics are for a Reply-To line with no mailboxes in it.

Note also the description of "group" in section 3.4:

The group construct allows the sender to indicate a named group of recipients.

Again, this does not envision using a group in a header like Reply-To. But that is what the current reply-to construct permits.

Summary: The RFC either needs to forbid Reply-To with zero mailboxes, or it needs to explain what the semantics of such a Reply-To are.
--VERIFIER NOTES--
Reply-To has allowed address lists (as against mailbox lists) as far back as RFC 733. This would be a change to long held consensus. Not appropriate for an erratum.


Errata ID: 3088

Status: Rejected
Type: Technical

Reported By: Michael Redwine
Date Reported: 2012-01-11
Rejected by: Pete Resnick
Date Rejected: 2012-02-20

Section 3.3 says:

date-time       =   [ day-of-week "," ] date time [CFWS]

It should say:

date-time       =   [ day-of-week "," ] date time [comment]

Notes:

If using the [CFWS] at the end of the original text, by the rules of CFWS, the next line could contain only FWS after the CRLF, which would violate the requirement found in 3.2.2, which reads: "...where CFWS occurs in this specification, it MUST NOT be inserted in such a way that any line of a folded header field is made up entirely of WSP characters and nothing else."
--VERIFIER NOTES--
CFWS allows there to be multiple comments, including comments that go on to the second line, which is perfectly OK.


Errata ID: 3675

Status: Rejected
Type: Technical

Reported By: David Hoerl
Date Reported: 2013-06-29
Rejected by: Pete Resnick
Date Rejected: 2013-07-08

Section 3 says:

3.2.3.  Atom Says:

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

3.2.4.  Quoted Strings (but superseded by Errata 3135) Says:

   quoted-string   =   [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [CFWS]

3.4.1.  Addr-Spec Specification Says:

   addr-spec       =   local-part "@" domain

   local-part      =   dot-atom / quoted-string / obs-local-part

   domain          =   dot-atom / domain-literal / obs-domain

   domain-literal  =   [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

It should say:

3.2.3.  Atom

   dot-atom        =   [CFWS] dot-atom-text [CFWS]

   dot-atom-lh     =   [CFWS] dot-atom-text [FWS]

   dot-atom-rh     =   [FWS] dot-atom-text [CFWS]

3.2.4.  Quoted Strings (but superseded by Errata 3135)

   quoted-string   =   [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [CFWS]

   quoted-string-lh =  [CFWS]
                       DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
                       [FWS]

3.4.1.  Addr-Spec Specification

   addr-spec       =   local-part "@" domain

   local-part      =   dot-atom-lh / quoted-string-lh / obs-local-part

   domain          =   dot-atom-rh / domain-literal / obs-domain

   domain-literal  =   [FWS] "[" *([FWS] dtext) [FWS] "]" [CFWS]

Notes:

Section 3.4.1 states "Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec.", yet the ABNF specifically allows it without recourse to obsoleted terms. Given that the above statement is in fact correct, then the current ABNF should be modified as shown to reflect the above statement.
--VERIFIER NOTES--
The DRUMS Working Group made a conscious decision at the time of writing 2822 that they preferred clarity and ease of understanding of the ABNF at the expense of shift-reduce conflicts and other things that had to be limited in the text descriptions of the syntax, and that assumption carried over into 5322. This is one of those cases. While more precise, the correction is not what was intended, and there are many other cases where the text limits the more free syntax.


Errata ID: 3400

Status: Rejected
Type: Editorial

Reported By: Christoph Anton Mitterer
Date Reported: 2012-11-06
Rejected by: Pete Resnick
Date Rejected: 2012-12-10

Section 3.5. says:

   message         =   (fields / obs-fields)
                       [CRLF body]

   body            =   (*(*998text CRLF) *998text) / obs-body

It should say:

   message         =   (fields / obs-fields)
                       [CRLF body]

   body            =   (*(*998text CRLF) *998text) / obs-body

It is RECOMMENDED that message bodies are terminated by CRLF, though 
this is in principle not necessary (this does not apply to messages 
consisting only of a header section, as header fields are always CRLF
terminated).

Note however, that when transporting messages via SMTP the last lines 
of message bodies MUST be terminated by CRLF as specified int 
RFC 5321, section 4.1.1.4.

Notes:

Hi folks.

AFAIU, the definition of body allows message bodies (not header sections) that end without CRLF.

RFC5321 section 4.1.1.4. however states: "The mail data are terminated by a line containing only a period, that is, the character sequence "<CRLF>.<CRLF>", where the first <CRLF> is actually the terminator of the previous line".

So SMTP forbids, what this RFC allows.
I guess the SMTP RFC can't be changed here and it makes no particular sense to restrict RFC5322 on the other hand.

My suggestion was to add this clarification.

Perhaps a similar one should be added to RFC5321, telling that Internet Messages themselves wouldn't need the last CRLF.
--VERIFIER NOTES--
It is clearly a change from WG consensus to add any normative 2119 text regarding a terminating CRLF. (See archive of the DRUMS WG, 17-18 March 1998 in a thread with a subject of "Small Clarification to msg-fmt-04".) The CRLF is not required for the message syntax. There are things other than this that 5321 cannot transport, so is also unlikely to be in scope for 5321 as an erratum either. Perhaps a discussion of this might be useful for RFC 3030, but again, it is unlikely to be an erratum.


Errata ID: 2619

Status: Rejected
Type: Editorial

Reported By: Dominic Sayers
Date Reported: 2010-11-10
Rejected by: Pete Resnick
Date Rejected: 2011-05-16

Section 3.4.1 says:

      It is therefore
      incumbent upon implementations to conform to the syntax of
      addresses for the context in which they are used.

It should say:

      Implementations MUST conform to the syntax of
      addresses for the context in which they are used.

Notes:

The phrase "incumbent upon" is not defined in RFC 2119. If another RFC defines a standard with the force of "MUST", then it is not an option for an implementation to ignore that standard. Therefore, implementations MUST conform to their syntax.

This rewording clarifies the recognition that should be given to the RFCs that inform the particular context of the implementation.
--VERIFIER NOTES--
Conforming (or failing to conform) to the syntax of another specification does not affect the interoperability of *this* specification. Therefore, RFC 2119 language is not appropriate. However, even if it could be argued that it was, an erratum is not the appropriate place to make such a change.


Errata ID: 2620

Status: Rejected
Type: Editorial

Reported By: Dominic Sayers
Date Reported: 2010-11-10
Rejected by: Pete Resnick
Date Rejected: 2011-05-16

Section 3.4.1 says:

   Comments and folding white space
   SHOULD NOT be used around the "@" in the addr-spec.

It should say:

   Comments and folding white space
   SHOULD NOT be used around the "@" in the addr-spec. Comments and
   folding white space at the beginning and end of an addr-spec are
   semantically invisible.

Notes:

Section 3.2.2 says

"Runs of FWS, comment, or CFWS that occur between lexical tokens in a
structured header field are semantically interpreted as a single
space character."

but a leading or trailing space on an addr-spec would prevent it being interpreted as a valid RFC 5321 Mailbox (see http://tools.ietf.org/html/rfc5321#section-4.1.2).

This is important because this section of RFC 5322 also says

"It is therefore
incumbent upon implementations to conform to the syntax of
addresses for the context in which they are used."

Either the leading and trailing CFWS should be semantically "invisible" or additional logic is required for implementations to transform an RFC 5322 addr-spec into an RFC 5321 Mailbox.

Note: It may be true that leading and trailing CFWS is not "between lexical tokens". If so then it should be made clear what semantic interpretation to put on it in this case.
--VERIFIER NOTES--
1. "addr-spec" does not appear in 5321. 5321 and 5322 have two different definitions for "Mailbox" and "mailbox" respectively, and that is a topic for an update of these documents, not for an erratum.

2. This report does not want the CFWS to be *semantically* invisible; it wants it to be *syntactically* invisible when moving an addr-spec from a 5322 context to a 5321 context. This document does not discuss this use.


Errata ID: 3134

Status: Rejected
Type: Editorial

Reported By: Ashley Willis
Date Reported: 2012-02-25
Rejected by: Pete Resnick
Date Rejected: 2012-04-28

Section Appendix A.5 says:

   From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

It should say:

   From: Pete(A nice \) chap) <pete(his account)@silly.test(his host)>
   To:A Group(Some people)
        :Chris Jones <c@(Chris's host.)public.example>,
            joe@example.org,
     John <jdoe@one.test> (my dear friend); (the end of the group)

Notes:

Errata 2515 and 2579 change the above text, but there is no change needed to the original RFC. The quote from Section 3.4.1 says "SHOULD NOT", not "MUST NOT" ("Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec."). The example in A.5 "is aesthetically displeasing, but perfectly legal." It's meant to highlight extreme cases.
--VERIFIER NOTES--
Though unstated in the text, the intention of the WG was that the examples in A.1-5 were intended to be messages that conformed to all of the MUSTs and SHOULDs of section 3. Indeed, RFC 2119 defines SHOULD NOT to mean effectively MUST NOT unless you have fully understood and weighed the reasons for choosing a different course. The description below the example says that it is "aesthetically displeasing, but perfectly legal". I don't think violating a SHOULD NOT makes it "perfectly" legal.


Report New Errata