Re: [Jmap] Submission

[Ned Freed <[e-mail]>]

> > I think you've convinced me that while it is surely easy to write a
> > server-side envelope synthesizer, it looks hard to write a high-quality
> > and robust server-side envelope sythesizer.

> Right, and even then, if a client can't put parameters on the envelope,
> it's not going to be very satisfactory.  On the other hand, if you do have
> an explicit envelope with parameters, a lot of other stuff falls out
> naturally.

> For example, the marinate* option that people were arguing about is the
> FUTURERELEASE extension defined in RFC 4865. with the HOLDFOR and
> HOLDUNTIL parameters.  No need to invent anything, it's already there.

> I hope Ned Freed weighs in here, since he's done more hand to hand combat
> with this stuff than anyone.

I'm following the discussion, but I really have had nothing substantive to add
to what you and Chris Newman have already said.

In regards to envelope synthesizers, I guess I should note that we find we have
to tweak ours fairly regularly to keep up with interesting new ways various
pieces of software manage to implement someting other than RFC 5322. So not
only is writing a good one difficult, it's something you never really finish.

And since you've brought up the FUTURERELEASE SUBMIT extension, it's worth
pointing out the fundamental incompatibility between, on the one hand, people
saying that the "marinate until", aka FUTURERELEASE, capability is highly
desireable and widely used and other people saying that there are no SUBMIT
extensions worth considering.

More generally, the only difference between a JMAP capability tied to, say,
a magic header and a SUBMIT extension is syntax. But if you specify things
in a way that makes it difficult to map from one to the other, you'll pay
the price for that as long as either protocols continue to evolve - and that's
going to be a long time.

				Ned