Re: Jmap?

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--===============7693471546519585600==
Content-Type: multipart/signed;
    boundary="=_ripper.email-scan.com-182800-1777333973-0001";
    micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 8bit

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_ripper.email-scan.com-182800-1777333973-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Alessandro Vesely writes:

> On 26/04/2026 23:16, Sam Varshavchik wrote:
>> Alessandro Vesely writes:
>>
>>> Hi all,
>>>
>>> are there any plan, or even remote thoughts, about implementing JMAP =
for =20
>>> Courier-MTA?=C2=A0 It seems it's slowly gaining some traction...
>>
>> This is the first time I'm hearing this name, I don't know anything ab=
out it.
>>
>> I did come across the updated revision of IMAP, IMAP4rev2, a few years =
ago. =20
>> It also came out of the blue, for me. It was also a random, chance =20
>> encounter. It popped up in my Google search results, and I don't remem=
ber =20
>> what I was searching for, but there it was. I intentionally kept my mo=
uth =20
>> shut, and nobody mentioned it to me directly in the years that followe=
d. So =20
>> that pretty much says it all (and after skimming through the specifica=
tion I =20
>> pretty much forecasted this level of enthusiasm).
>
>
> Yeah, I'm more or less as enthusiast as you are, but I didn't skim the =
spec.
>
> Cyrus apparently implements it.  And I see more and more people asking =20
> Thunderbird to implement it.  It seems like sooner or later it's coming=
.

Well, the only thing that a search for "JMAP" found was RFC 8260, "The JS=
ON =20
Meta Application Protocol". This does not sound like an evolutionary step =20
for IMAP, but rather something completely different.

>> The JSON Meta Application Protocol (JMAP) is used for synchronising
>> data, such as mail, calendars, or contacts, between a client and a
>> server.  It is optimised for mobile and web environments and aims to
>> provide a consistent interface to different data types.

As The Church Lady once said: "Well, isn't that special?"

Translation: "IMAP is losing mind-share, IMAP4rev2 has not fixed it, so =20
let's get rid of this flaming dumpster, and start from scratch". I must =20
admit that I cannot find any fault in this reasoning, in theory. But just =
in =20
theory.

>> This specification is for the generic mechanism of data
>> synchronisation.  Further specifications define the data models for
>> different data types that may be synchronised via JMAP.

Translation: well, this standard isn't really a standard of any kind.

I will say one argument in favor of this. I've found, over the years, tha=
t =20
the quality of an Internet standard is inversely proportional to the numb=
er =20
of pages it takes to define it it.

RFC 3501 was 108 pages.

RFC 8620 is 90 pages.

At least it's a step in the right direction, but not by much. As a =20
benchmark, the venerable RFC 821 was only 68 pages, and RFC 2821 goes to =
79 =20
pages. RFC 1939 puts them all to shame, at just 23 pages. Now that's what =
I =20
call a standard.

Anyway, our fearless overlords have only 18 pages left, to specify =20
whatever's left to be specified, for a complete implementation for mail =20
transfer. What are the chances that they'll make it under the gun?


--=_ripper.email-scan.com-182800-1777333973-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCae/21QAKCRCKYPgoojZS
4ni4APwNMtmwBRKngmEAq6ouQfvEDkFalA2Xkf7ox0njwMqE0gEAilV+Qvfu5hq2
S80b4D1BVmYWL8hk6b858IvDAK3QwgE=
=5oLd
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-182800-1777333973-0001--


--===============7693471546519585600==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============7693471546519585600==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

--===============7693471546519585600==--