Re: [ietf-smtp] Fwd: Request to form a new WG: JMAP

This is a cryptographically signed message in MIME format.

--===============7477028636651109320==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="------------ms030907030201010706040102"

This is a cryptographically signed message in MIME format.

--------------ms030907030201010706040102
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 11/09/2016 08:15 AM, Ned Freed wrote:
>
> ... so this is a wash. ...
> ... This is also a wash. ...

Good :-)

>
> Binary MIME has been around for almost 25 years. SMTP was extended to
> handle it not long after itKaia FIT Boise was defined. And note that it=
's entirely
> possible to use binary MIME only on SUBMIT and not depend on the
> rest of the infrastructure handling it.

Yes, MIME is awesome. However it is now possible to send, transfer, and=20
fetch full binary data. The encoding/decoding cycle now seems to be more =

of a habit, than a need. Time to reverse this process and only encode=20
when requested?

> IMAP has had the ability to transfer parts in binary for a long time. A=
nd
> IMAP also offers the ability to decode and transfer a encoded part on
> the server side.
>
> JSON doesn't support binary, but there are various extensions that do.

Yes, that is my point earlier.

>> ...The complexity of the requests and replies are the issue. If its mo=
stly
>> converting IMAP to JSON, the same problems are going to exist.
>
> Yes and no. Part of the problem with IMAP is that it was designed for
> a very different sort of client than what we have now. (I note that the=

> problem SMTP is intended to solve hasn't changed nearly as much.) Getti=
ng
> rid of historical baggage will definitely simplify things.

Yes, it was mostly used by command line tools, that allowed you to save=20
attachments as files and to decide what part of email you wanted to view.=



> IMAP also uses an unnecessarily large number of format variants.

YES!

> OTOH, there's absolutely no doubt that there's considerable intrinsic
> complexity in the message access space. Especially given the desire to
> push more and more of the problem to the server.
>
> On the flip side, basing things on HTTPS adds an enormous amount of
> inherent
> complexity. But most of that complexity is hidden from the majority of
> developers, who won't code HTTPS support directly, preferring instead t=
o
> use any one of the bazillion libraries out there that does it all for y=
ou.

Problems that would need to be solved first:

What does a modern MUA's need?

I am not talking about what it takes to make an IMAP aware MUA work. I=20
mean what functional needs do they have? (Fetch, fetch body part,=20
notifications, get summary information, ...). If the goal is to make=20
this new protocol so much like IMAP as to make the coding converting an=20
IMAP MUA to a new-protocol faster? Or is the goal to do whatever the=20
correct new thing is?

Most of the IMAP command were designed to make command line tools work.=20
Those limitations no longer exist. You would get a summary of headers,=20
pick which ones you wanted to read. Then perhaps download the attachment =

and save it to a file.

I think the new message fetch protocol could be much simpler.

Polling for email was needed years ago because most computers (or the=20
programmers) had difficulty performing asynchronous notifications, or=20
multi channel I/O.

Does the new protocol have the server parse the headers and hand them=20
over in a more simple-client manner? (You have 10 headers, here they are =

(left side/right side). Or does it send a blob of headers and the MUA is =

responsible for the parsing? Same with body parts.

Does the new protocol help with securing the content in any way? If the=20
can is opened, should this be in the that mix of what's changing? How=20
can it not be a major issue?

What is needed at the functional level?

> My guestimate is that - and here I'm speaking only of the message acces=
s
> space
> - that a HTTPS/JSON approach wins in terms of effective implementation
> complexity, although it is far from clear to me by how much.

I am not a HTTP(s) solves every protocol problem person.

If the WEB MUA had different needs, what exactly are they?
Do they want the HTML formatting done on the server side? Some of it?=20
One of the many SMTP, IMAP, and POP ports are already opened on any=20
firewall that needs email.

One problem with putting email on port 80/443 is that some companies=20
need to control customer private data. And they would now have to block=20
by content, not by port. Much is more difficult.

What functional differences are their between WEB email and application=20
clients? What differences are their between mobile device needs and deskt=
op?

Doing JSON because its the new thing as the reason, I would think is an=20
insufficient reason to disrupt the email process.

This process is going to be a nightmare if the functional needs are not=20
nailed down first.

--=20

Doug Royer - (http://DougRoyer.US)
[email protected]
714-989-6135


--------------ms030907030201010706040102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CuwwggUCMIID6qADAgECAhAdBOVkkNcrCTidq3YMdkiJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwNDA3MTQyMjU5WhcNMTcwNDA3MTQyMjU5WjBIMR8wHQYDVQQDDBZkb3Vn
bGFzcm95ZXJAZ21haWwuY29tMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21haWwu
Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwpXz2U03EAEwBMtWerSb3KUI
IfTw2/55rms1TwBY+p4Jj7x4DWTlBF6Ur5rdFF70bydWtDGILvSI3BNY2eXjZzbSXl5HCmvZ
gUNnYFw6SJkb4S7edV5VdXVdOAVh24y0OBWqedbbuT8eVDZfPTy1mOuUbZo0I0tCoa1Hky14
UDb2qtPKw2Wfn9o2ksubBvn2b0UZlPahGFAcC/qc8M9h0O1G1hsn0BIowvVdr73/Q17Znr9u
J/CBaCkNCM2tzH5j1qov7hRRZmeb7mVHrf/Dina9JjBAKsz52KZczLqPz1mSycKiEKc/k0ag
FNtl0l6tCpUcoHwzBQ6dlbNOQEtE2QIDAQABo4IBuTCCAbUwDgYDVR0PAQH/BAQDAgSwMB0G
A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQkN0Oa
JE+zG3ATs7D0DgRxVGx0fzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggr
BgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5Bggr
BgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQx
LmNybDAhBgNVHREEGjAYgRZkb3VnbGFzcm95ZXJAZ21haWwuY29tMCMGA1UdEgQcMBqGGGh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIFMCwwKgYI
KwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsF
AAOCAQEAhAL0TajC+aJEbVC9q1elm0H0qgeCyW7EpLcfg8Lxwz/B9r6LvgoDzyS2afLecviF
dy37I6jKVIAQH4RmAzVRwkSr1BHAl9TjSIQvlSbanoRnkLxJSWOr5fBiqbwrogv7K10tRGwN
+86UIBvfear2f9epnMcI9d/hs4y6t41/uHlU76X5NdHIladYznv2YbZ9RJHUgaQvVYPkMzhA
8AqIVw/2r+RCJLA65Nf1prGxgQhTeA/JjTLVgjaO3AMtj9OQ/xm8NNVXhvLhRzhTXrXbux2q
xWjYrPcMTiTrtsQyAZ9kbTaf5S2BErTA6EK5RQfZWFZCIlgI5XhVoHhOAMAchjCCBeIwggPK
oAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx
FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRp
ZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y
aXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAU
BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d5
2DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8
wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDt
VB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwv
IjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1
ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzApMCegJaAj
hiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEEWjBYMCQG
CCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKGJGh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+SQ+PtxtG
K8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0gBDgwNjA0
BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTAN
BgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdOruKb
rWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM
3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/
b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uV
rZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDT
agXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SW
JQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0f
QoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8
wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S
4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPMMIIDyAIB
ATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs
YXNzIDEgQ2xpZW50IENBAhAdBOVkkNcrCTidq3YMdkiJMA0GCWCGSAFlAwQCAQUAoIICEzAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDkxOTU2MjZa
MC8GCSqGSIb3DQEJBDEiBCACBJ045Q51Sm6OAOe8ylcUq1wXsVQiRX/ty3Gl6JM+tDBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGa
BgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0
ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQD
ExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTCBnAYLKoZI
hvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpT
dGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHQTlZJDXKwk4nat2DHZIiTANBgkqhkiG9w0B
AQEFAASCAQAwhCk8WXMk0nM0CFY7V6L1IWqcH1/fhysEv6dVJ/cIqokxOnzqHkmB+PmwGF0I
E/aQqNkWMFf4/6cJyp8sRKLCNmJUHLIIsLUeNfk2WN3iV1SWhdHG6DSS2/RelxjJD2nRzy4r
/QhMt1+RuU+47GLh9/QdNV7xTYT4aog6NtWZD5c49SXQ1Q52x5S8xg0ZRKd7VtCw+ZiKjidB
IEURm+v9O4lDPltzUSqLL9HtG0QoVuX9n6p7GcyFa38jIp2+UYZhyfRGMQCVXXJA/Vf5nDHn
doDrd8QnJFc0diqn0/DmI+n+tpvsFo2w1Yux1EOHoO8mOIroK7jUJtzPJS+/wxf8AAAAAAAA

--------------ms030907030201010706040102--


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

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext

--===============7477028636651109320==--