Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01

[Josef 'Jeff' Sipek <[e-mail]>]

On Mon, Sep 04, 2017 at 11:39:51 +1000, Neil Jenkins wrote:
...
> On Thu, 27 Jul 2017, at 12:10 AM, Josef 'Jeff' Sipek wrote:
> > Why is accountId required in the [download] URL?  I don't see a reason
> > why a server> couldn't use blobIds that either have internal structure to correctly
> > determine the accountId, or to not care about accountId at all.
> 
> All ids in JMAP are scoped to a particular account, and this includes
> blobIds. Depending on how your server works, you probably need to know
> the account in which to look for a particular blob, so it needs to be in
> the URL. You could just include it in every blobId, but why make all the
> ids longer when you don't really need to?

Agreed.

> > I'd expect the spec to say that the URL MAY contain accountId
> 
> We could make the accountId optional in the download URL; it should
> pretty much make no difference to the client. Then if you don't need it
> on the server you can just exclude it from the URL template.

Exactly.  That's what I expected when I started reading the draft.

...
> > it is easy to run into a ugly scenario where a client wants to save a
> > draft with two large attachments with quota enabled.> […]
> > I think it would be good for jmap all requests to either succeed or
> > fail in a way that tell the client what can be done to get more
> > forward progress (even if it is sub-optimal) or that there is no way
> > forward.  In this particular example, the issue is that the
> > invalidProperties error returned from setMessages covers multiple
> > situations.  At least some of them are:> 
> > (1) client error: the client didn't upload the attachment before
> >     trying> to reference it
> > (2) blob expired: the server removed the blob because it remained
> >     unreferenced for too long
> > (3) blob evicted: the server removed the blob early because of over-
> >     quota>     situation, etc.
> 
> Both (1) and (2) of course just mean the client has to upload the
> attachment. But yes, I agree the eviction case is problematic. The way I
> was thinking about it was that eviction is an edge case just specified
> to allow the server to stop abusive behaviour. I was presuming your temp
> space has a separate quota to your regular space, which should make your
> issue very unlikely.

Hrm... I haven't considered a separate temp space quota.  I'll have to think
about this a bit more, since it doesn't obviously make me convinced that the
client can distinguish between (1) and (3) above.

> If you had a (say 250 MB) temp space quota (and we presume a message has
> a max 50MB attachments limit), you're unlikely to get eviction unless
> the client is doing something either malicious or stupid.

Agreed.  (5 clients uploading 50 MB each at the same time can make the
250 MB disappear in no time, but I think that's not something we can or
should address.)

> If I note this in the spec, does this resolve your concern? If not, do
> you have another suggestion for how to provide limits that stop
> malicious/broken behaviour from causing issues?

I was thinking about somehow trying to inform the client so it can
distinguish the there cases.  E.g., something like:

(1) client error: return invalidProperties + CLIENTBUG
(2) blob expired: return invalidProperties + BLOBTIMEOUT
(3) blob evicted: return invalidProperties + OVERQUOTA

This way, the client can make a better decission how to handle the error.
For example, when the QVERQUOTA case is encountered, the client can avoid
retrying (which would only waste bandwidth), and either just tell the user
or for some clients try to sell the user more storage (which presumably
would have a larger temp space quota as well).

This is the kind of thing that I'm thinking about.  (FWIW, it's still not
fully formed in my head.)

> > By the way, a number of the HTTP status code descriptions
> > include: "There> is no content in the response."  Is that saying that the response body> SHOULD be ignored?  Or that the responses' Content-Length MUST be 0?
> 
> I was presuming Content-Length MUST be 0. But it might be helpful
> for servers to return diagnostic text here, so I'm happy to just
> change it to "Clients SHOULD ignore the response body". Do you think
> this is better?

Yes.

Of course there is the whole argument about abuse of HTTP status codes.
I don't have an opinion about this myself (and I haven't looked into this in
detail), so I'm merely relaying the concern.  I've been told that jmap
should follow the advice in:

https://tools.ietf.org/html/draft-nottingham-bcp56bis-00#section-4.6

Thanks,

Jeff.

-- 
It used to be said [...] that AIX looks like one space alien discovered
Unix, and described it to another different space alien who then implemented
AIX. But their universal translators were broken and they'd had to gesture a
lot.
		- Paul Tomblin