Ready to go
Since our charter requires implementations, should use RFC7942
implementation status in all our drafts. (editors to remove)
Barry: 7942 says "remove the implementation section"?
Ken: no, suggests you add it while you're working on the draft. That's
what I agree on.
Barry: no, not suggesting after. But leave it until approved.
Feedback from Matt (all done on list)
Daniel: just updated language and reorganised sections. Think waiting
for AD?
Ken: not sure if have pushed button, otherwise will do so now.
Andy (AD): is already out for last call. On the telechat agenda.
Daniel: allow servers to give "near enough".
Think nearly ready to get it out the door.
Ken: Barry's feedback from review should be taken.
Alexey: sorry to be a pain, not super happy with last change. Don't
think that the server should return data that the client didn't ask for.
Think I understand and accept the case for returning less than asked. If
the server has more than it should return - can filter out some.
All Arnt's fault.
Daniel: don't have strong feelings one way or the other.
Alexey: my preference is roll back the higher limit - make it a hard
limit. Happy to suggest "if the server can only do more, it just has to
filter it out".
At the moment the hard limit is linked to MESSAGELIMIT but if you roll
this back, also provides that.
Barry: agree with Alexey. Can see implementation where you allocated
data structures for a particular number of responses. You can throw them
away on receipt but the server can throw away too, let's not waste
bandwidth.
Arnt: We have the messagelimit extension to get hard limits. We
generally don't have extensions that bind non-implementing code. I think
that's good. All our extensions say "software that suports this
extension should do or must do". Should be moving to JMAP anyway so I
don't mind.
Barry: don't agree with Arnt's characterisation. Saying server can
respond with less but not more. It's fine for UIDBATCHES to say "can't
return more than you ask for".
ACTION: Daniel to look at Barry's review on the list, and update the
UIDBATCHES draft to remove the "allow more than asked"
Rik: most effective extensions to implement. Talked in Dublin, updated
based on discussion.
PREVIEW was removed.
Should we explicitly include "already in rev2?"
Do we want to put in the "everyone already supports them?"
Should we hold off for OBJECTID?
Should this be an AS?
Barry: Yes, make it an AS. The only thing there is "it becomes a
proposed standard", it's not in the metadata. This should be the last in
the batch of current changes, so you can pick up.
Eliot Lear: why should it be an AS?
Barry: the point of an AS is "how to use existing standards". This is
doing exactly that.
Eliot: I have a different understanding of AS. They tend to apply to
specific standards. Applicability of this standard is as follows. This
feels a lot more like a profile.
Rik: that was also discussed.
Eliot: there's a risk with profiles. This could make it more difficult
to introduce new extensions.
Barry: believe document also says "this is not the definitive list", if
wording isn't clear enough, suggest alternative.
Eliot: suggesting "if we say the minimum of something, they will
interpret them as the maximum".
Alexey: as a counterpoint, we did LEMONADE in the past and this didn't
happen. Hear you but not concerned.
Rik: one thing that's be useful is that this is a useful set of
endorsements.
ACTION: Rik to wait for progress on other specs and integrate them into
extensions-list doc.
Hans-Joerg: there are proprietary things like Google Takeout etc.
There's MIME for individual items, maildir, mbox. Not perfectly
standard, and not something an end user can deal with.
Q: What do we do with encryption?
Mauro: am planning to implement this, even if it's not ready. Wanted to
make comments about the calendar and contacts bit. Saw the scenarios
where you can lose data in the conversion. Servers in caldav/carddav may
not want to export in that format. May want to allow jcal instead; would
suggest a setting where the server can allow export into jcal instead.
Second comment: would be nice to extend JMAP to have a checkout/import
method for importing/exporting an entire account.
Hans-Joerg: that's on our mind and makes sense, would do that
separately.
Barry Leiba: It's not clear to me whether you're thinking of
export/archive, or a server to server protocol.
Lisa (co-author): not creating protocol bindings. They would be great,
so would server-to-server. The format even without bindings is valuable,
so concentrating on that first. Even without server-to-server, people
are motivated enough to drag things over. Would like to do this first,
then will work on protocol bindings.
Barry: let me encourage you not to leave encryption to too late a stage.
Alexey: does encryption need to be part of the format, or part of the
security consideration.
Ben Bucksch: first question was "will there be an API"? One way to do an
API is to have a local application. Would be happy to support this
inside a local application.
Incremental backups. Don't think tar gz is good for adding/removing
things, while zip allows you to add/remove.
folder.json will reference individual emails. Then you have a single
file that's read/write all the time. Consider using filesystem to list
the content of the directory.
Hans-Joerg: thanks for comments. Short comment to incremental backup.
You'll see it in a draft. Currently the idea is not to update the
existing file, but since this is something you pull, we thought an
incremental archive that tells you changes.
Bron: tar.gz can be concatenated. Suggest having a format that allows
multiple bundles, lets you combine partial exports, and also encrypted.
Pete: calendar stuff, particularly with invites, is hard! Unless you're
planning to solve all those problems, think asking for trouble adding
them to this.
Hans-Joerg: migration enthusiast, happy to discuss it with you.
Neil: calendar stuff: migration should work OK - you need to know "which
addresses in this file should be considered you". If keeping the same
address, should work fine.
Ken: hopefully http-bis will help.
Neil: question is "do you need to wait for the whole thing", or can you
start already. Depends on the type?
Neil: main question is "can your upload tool extract the data and upload
it separately".
Alexey: thanks, all great input. Question for chairs, there's a
half-done adoption call. Nobody replied to email.
Lisa: will follow up with Neil on list.
Arnt: settled on using PRECIS for most things.
Barry: does each part have to all RTL or LTR?
Arnt: TLDs must be single direction. Second level in TLDs must be one
direction except .com which has an old database. In own third level you
can do what you want.
Some writing systems use accents, some don't. Hard to tell if something
is being used in an incomprensive way. e.g. there's a band from Russia
which does this. Say "ignore them". Shouldn't be a security problem
because public domains keep it from being usable as an attack vector.
Length limits for localparts: there's a theoretical 64 byte limit. Some
address verification services use 50. Want to mention the 64 and
otherwise not limit it. There are bots on th eweb which try to sign up
extrememly long addresses.
John K: I'm troubled by this list of ignore things in something that's
intended to be an IETF spec. These limits are not present in CCtlds.
Need to look carefully at the boundaries. If they bind ICANN things then
it's an ICANN issue.
Arnt: One of the CCtlds only has a single test domain registered, which
is a test one. Unable to find any email address or domain which uses
this. After several months of looking, unable to find.
John: Say "nobody we found is doing this, doesn't seem necessary or a
good idea.".
Arnt: thanks, will add wording to that effect.
John L: have some miscelaneous thoughts. 64 byte limit is needed, know
of production mail servers with fixed size buffers. 64 bytes in a
unicode address is less than 64 codepoints.
Arnt: maybe misread 8264? That's why I didn't include it.
John L: many systems allow +suffix. This doesn't. Is that an accidentaly
ommision?
Arnt: my interoperable addresses is for people who don't have
sub-addresses. That's added after you provision an address.
John L: that's how it's implemented, but addresses with plus signs is
just an impementation detail. My plus addresses have hyphens, so I'm
neutral on this one.
Alexey: may be stating an obvious thing. This document is updating the
emailcore AS recommendations. My personal take is "I want to get
emailcore AS done", this will update that once it's published.
Arnt: will write a complete implementation first. Then would like to do
WGLC, not IETF last call until emailcore AS is done.
Neil: haven't done any slides, not much to say. Hasn't been changed
since last time. Basically ready, but need implementation status. It's
implemented at Fastmail, please test with us!
Once we have an implementation, we can progress to last call.
Doesn't need to wait for autodiscovery, it's independent of it.
Ken: asked OAuth chairs to have it checked. Will ask them to look at it.
Ben: also no slides.
Lots of good comments, should be all addressed or a reason why not.
Haven't done XML schema, haven't found a way which allows undefined
elements and attributes which are important for forward compatibility.
If anyone can help me, that would be good!
Murray: I'm shepherd, and will review, but others are free to as well.
ACTION: people to review
Daniel Eggert: lots of good discussion on the mailing list.
DKG: what do you do if the fallbacks aren't bitwise identical, or if you
can't fetch one.
Daniel: spec goes into details that everything must be bitwise
identical, but if you mx fallback you get multiple high priority -
someone can squat.
DKG: right way to deploy is to put it everywhere. Quesiton is "what do
you do if it's not deployed the right way?"
Daniel Eggert: if you do the main and it works, you just pick that one.
If you can't read the server, THEN you can do the MX fallback. If there
are multiple highest priority. If any fails, then you consider it to
have failed.
If one client could connect directly, other got fallback, then they
could get different config.
Neil: just wanted to ask about the digest. Offering 3 different hashing
algorithms seems needless, would like to just choose sha256. Adding
options is a mistake if we can avoid it.
Daniel: no strong opinions about that.
Neil: mostly we're moving towards "if it becomes insecure, bump the
protocol."
Arnt: agree with Neil.
Daniel: there are pros and cons. I have some feelings about it.
Ben: MX fallback? In practice, this is the only way that autoconfig
works. About 90% of the domains resolve via MX fallback. 5-10% resolve
directly. Helps with Google, own company domain hosted with another
provider, etc. You won't have the relevant DNS entries. The MX fallback
allows the provider to set the correct records.
Arnt: basically the fallback allow the mechnaism to jump to high
deployment.
Neil: not sure that the MTA-STS requirements make this still hold.
Bron: the MX fallback is still a lot safer than the AI people look at.
Daniel: yes, but if they look up things via an AI, then you can blame
the AI. If we provide the details, they'll blame us! Apple won't do this
without it being secure.
Ken - it's information - intentional?
Ken - do you have plans to implement it soon?
Mauro - implement in 2-3 months.
dkg:
Ben: could reuse the same label as legacy autoconfig.
Ken: IANA asked whether we want to reuse serivcename registry, or create
something fresh?
Alexey: Just a list of SMTP/IMAP/JMAP/WEBDAV/CALDAV etc. Already in the
servicename registry?
Rik: may want to add other things in future.
Bron: ask IANA to add a column?
Pete: don't think we need to do that. For the service you want, use
something from the protocol list. Here's how to do these ones.
Arnt: in the 90s we had a couple of registries with trivially different
names for the same thing. Refer to the registry.
John L: the servicenames registry has 20k entries. Making any change
would be a big deal.
Bron: big problem is caldav vs caldavs etc. We need to be clear. Then
we're creating a shadow registry in this document, why not make it a
real registry.
Ken: ABNF for IMAP response codes, can't have multiples unfortunately.
Might need to come up with a compound response code.
Alexey: you can send untagged responses. Clients that don't implement
it, then.
Mauro: what if client has to enable?
Ken: yes, if client enables then it's great.
Ben: if the mailboxid in the account is not unique. You can have a
schenario where multiple orgs are cooperating, and want to merge
accounts. You'll still run into the same problem. Propose you add an
additional serverid.
Mauro: don't think that makes sense. In JMAP you don't have that
concept. This would allow you to access a JMAP account. The mapping a
JMAP server provides is to the same server. It's assumed to be the same
server. If you need other information, use IMAP metadata.
Arnt: I know several codebases that don't properly tie untagged
responses to commands, and would be unhappy with an extension that
relies on them being done correctly. Thing it's a bug magnet.
Alexey: they're not going to implement this. If you don't opt in, you
don't get it.
Ken: if they opt in, we can extend the ABNF for response codes.
Arnt: much happier with extending ABNF to allow extended.
Ken: agree
Bron: suggest adopting this document. If you opt-in then the MAILBOXID
could be a compound value of ACCOUNTID/MAILBOXID.
Bron: would like the normalisation to be the same as DKIM relaxed
DKG: please send to the list! Sounds good. We have MIME headers on
parts.
Barry: agree document and discussion is in the right state.
Murray: is this too big for this WG?
Andy (AD): what does the WG think?
Barry: as a WG participant, this is arguably not maintenance. Would
normally say "something involving encryption is not for this WG" - but
this is simpler and only about signed, not encrypted.
Alexey: as long as we're not doing any crypto here, and just using the
output of work done elsewhere, this is just a new packaging variant, so
it's contained enough.
Murray: want to not have Andy get caught later. This is novel, not just
tweaks to IMAP.
Andy: Agree, it's maybe close.
Barry: or we pre-emptively recharter now?
Alexey: we should adopt, and if it becomes a problem we can deal with
it.
Pete: we take it to completion, and if the IESG whines we can do a
spin-up-spin-down for a single document.
Murray: it would be this group of people anyway.
Ken: do you have implementors doing work or planning to?
Alexey: an extra point, with a lot of email related security stuff, we
try to do it in LAMPS. People in LAMPS are too concentrated on crypto,
this is a better audience.
Murray: just want it on here.
Ben: what about S/MIME?
Daniel: think this will work for S/MIME too, I'll merge your MR if you
create one. Will open an issue, maybe others can do the text. Might ask
Alexey if it's good.
Hans-Joerg: FOSDEM in Brussels at the end of January/Start of February.
There's a "MODERN EMAIL" devroom. Would like to encourage people from
here to propose talks.
Murray: feel free to announce on the list.