Use semantic chunks in API, not ABNF chunks #15
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
mikedilger/email-format#15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The ABNF chunks defined in RFC5322 do not match exactly to the semantic chunks. For instance,
message-idis defined with angle brackets in the ABNF, but the text of the standard indicates that angle brackets are not part of the semantic meaning of message-id. Therefore, set_message_id() ought to not require angle brackets, but parsing/streaming ought to handle them appropriately.It gets weirder with whitespace. You might think whitespace following the colon after a header name belongs to the label somehow, but no, it belongs to the next token in the ABNF, defined as allowed via multiple ABNF constructions, the net result is that it just so happens to be allowed after every header name and colon. However, the whitespace is semantically not part of most tokens that allow it. How do we parse out and put in whitespace in a consistent manner, and not require callers to add whitespace to the token when they want a space after the colon (e.g. with
set_sender(" a@b"))?The changes implied here will likely break existing code, and potentially will be very extensive.