Comments (6)
So I'm inclined to say that the ergonomics of this are maybe up to users of this crate to handle. Then this crate can focus on providing a correct protocol implementation (using bytes wherever needed), and you can for example have rust-imap
offer a nicer API on top of this somehow.
This is kind of predicated on the notion that non-UTF-8 data will really only be a problem for message contents. Have you actually seen this be a problem for header data?
It also relies a little bit on my perception that using the message parsing parts of IMAP should mostly be avoided in favor of handling message parsing in the client application... Some parts of IMAP really seem like a layering violation that way.
from imap-proto.
@jonhoo: In my mind, we can just use bytes everywhere and add the UTF-8 API later. I think correctness and completeness of implementation is more important in this early stage than convenience. I'd like us to starting filing issues for missing implementations and bugs, and I'll starting working on them!
from imap-proto.
@djc:
-
Yes, headers can be non-UTF-8 as well. See e.g. https://tools.ietf.org/html/rfc5738#section-8.
-
Where shall we draw the boundary between this crate and the
mailparse
crate for message parsing?
from imap-proto.
Yeah, it's the non-UTF-8 headers that are the issue (in part because not all servers support UTF-8 up-conversion). We could comb through the specs to find which fields are safe to always parse as unicode strings, and which aren't, but it seems better (at least to me) to just have the user choose how to interpret text-like &[u8]
s using a trait like the one outlined in the first comment.
For what it's worth, I completely agree with you that if headers were all valid unicode, then this library should just use str
everywhere with the exception of message contents. Unfortunately, as @sanmai-NL points out, that doesn't seem to be a realistic assumption :( See also further discussion in mattnenterprise/rust-imap#11.
from imap-proto.
@sanmai-NL RFC 5738 is an extension, so that in my understanding a client should not have to support it.
As for the boundary between this crate and something like mailparse
(or my own email-parser
crate), I'm not sure how you see that? Especially focusing on the client implementation, according to my understanding an IMAP client is not required to do any email parsing; the server will need to do some of it to be able to return ENVELOPE structures, for example.
from imap-proto.
Interested readers should also see PR #12, and the reason for its closing.
from imap-proto.
Related Issues (11)
- Add re-export of nom's `IResult` HOT 2
- UNSEEN response data not parsed HOT 1
- Derive equality for simple types HOT 2
- LSUB response type not supported HOT 1
- Prefer variant structs over variant tuples HOT 1
- Fix integer overflow during parsing
- Error handling improvement HOT 6
- Private fields in `Response` type: how to get at contents? HOT 2
- Parse `FETCH ... BODYSTRUCTURE` response HOT 6
- CommandBuilder quotation HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from imap-proto.