|
|
|
|
Found 10 records.
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: 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: 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: 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: 1905
Status: Reported
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2009-10-09
Edited by: Alexey Melnikov
Date Edited: 2010-04-02
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: 1906
Status: Reported
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2009-10-10
Edited by: Alexey Melnikov
Date Edited: 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: 2104
Status: Reported
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2010-04-02
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.
Errata ID: 1905
Status: Reported
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2009-10-09
Edited by: Alexey Melnikov
Date Edited: 2010-04-02
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: 1906
Status: Reported
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2009-10-10
Edited by: Alexey Melnikov
Date Edited: 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: 2104
Status: Reported
Type: Technical
Reported By: Wolf Lammen
Date Reported: 2010-04-02
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.