Subject: [lemonade] Splitting Binary

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 20 Mar 2006 16:06:18 -0800

Some food for thought before Wednesdays sessions ...

Most (all?) of the issues with Binary seem to be with the append side. I 
think fetch can be cleaned up with a grammar fix to clarify literal+ 
interactions, and text explicitly calling out that you can only binary 
fetch terminals.

The big issue I have is with servers that don't support the append side, 
or do, but only on a subset of mailboxes.  I just don't see a clean way 
for the server to advertise the append-side capability.

I'm mulling the idea of splitting the current 'binary' into two new 
capabilities: 'bfetch' and 'bappend'.  This would solve the problem for 
those servers that can't or won't implement the append side.  It still 
doesn't handle the case where some mailboxes can handle bappend, but 
others can't.  My feeling here is that since the server now has the 
option of punting on bappend, if it *does* advertise the capability it 
*must* deal with it on *all* mailboxes.  Since bappend is an 
optimization for the client, I feel it's incumbent on the server to do 
whatever is necessary to actually optimize things for the client. 
Requiring the client to probe for validity is a non-starter in my books. 
  And it was always my intent in binary that servers would go out of the 
way to make bappend work everywhere if it worked at all; the new 
behaviour would make that a requirement.

I realize this is out of scope for both the WGs, but if we're starting 
anew there's a better chance of being able to tailor things to meet some 
of the requirements the Lemonade folks have been talking about.

--lyndon

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Mar 2006 18:37:52 -0600

Hi Lyndon,

> for the server to advertise the append-side capability.

Of course per-mailbox capabilities could be advertised via ANNOTATEMORE. 
That is something that we could formalize:

e.g. for an extension that may be offered on a per-mailbox bases, a server 
that advertises 'FOOBAR' in the CAPABILITY response always supports the 
foobar extension on all mailboxes. Whereas if the server advertises 
'OPTIONAL-FOOBAR' then it only supports foobar on a per-mailbox basis. In 
that case a new /capability annotation on mailboxes supporting foobar would 
list 'FOOBAR' as one of the capabilities - or its part of LISTEXT. This use 
of the 'OPTIONAL-' capability prefix can be used as a generalized way to 
handle cases like this. I don't know whether there is a benefit to 
separating these two cases like this...

-- 
Cyrus Daboo

---

From: Lyndon Nerenberg <[email-masked]>
Date: Mon, 20 Mar 2006 20:49:46 -0800

> Of course per-mailbox capabilities could be advertised via  
> ANNOTATEMORE. That is something that we could formalize:

But what do you do when the server doesn't support annotatemore?  The  
problem is still there.

--lyndon

---

From: Dave Cridland <[email-masked]>
Date: Tue, 21 Mar 2006 08:45:14 +0000

On Tue Mar 21 00:06:18 2006, Lyndon Nerenberg wrote:
> Most (all?) of the issues with Binary seem to be with the append 
> side. I think fetch can be cleaned up with a grammar fix to clarify 
> literal+ interactions, and text explicitly calling out that you can 
> only binary fetch terminals.
> 
> 
Although issuing a BINARY fetch for a non-terminal is obviously a 
SHOULD NOT, I don't think it's a MUST NOT, and semantics must be 
defined. (It's equivalent to a BODY fetch, because the CTE is always 
an identity one). My reasoning here is that although it's pointless 
to do a BINARY fetch on a non-terminal directly, some extensions have 
been proposed that internally perform a binary fetch before 
performing some other operation. LZIP and LCONVERT are defined like 
that, I believe.

> The big issue I have is with servers that don't support the append 
> side, or do, but only on a subset of mailboxes.  I just don't see a 
> clean way for the server to advertise the append-side capability.
> 
> capabilities: 'bfetch' and 'bappend'.

Or you could make it BINARY (binary fetch supported, may support 
binary append on some mailboxes) and BAPPEND (binary append supported 
[including CATENATE?] on all mailboxes). I can't see the case where a 
server supports upload but not download.

For per-mailbox capabilities, I'll just point at Cyrus's message - 
I've said before we need some standard mechanism for discovering 
per-mailbox capabilities.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 21 Mar 2006 12:04:41 +0100

> per-mailbox capabilities.

RFC 3348 uses LIST for the purpose, and I don't see significant 
drawbacks to that approach. We now have LISTEXT.

Arnt

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 21 Mar 2006 07:22:01 -0600

Hi Lyndon,

> But what do you do when the server doesn't support annotatemore?  The

At that point the client has to fall back to a 'try it and be prepared for 
it fail' behaviour. At least it will know to expect that if 
'OPTIONAL-FOOBAR' is advertised.

-- 
Cyrus Daboo

---

From: Mark Crispin <[email-masked]>
Date: Tue, 21 Mar 2006 06:05:32 -0800 (PST)

On Tue, 21 Mar 2006, Dave Cridland wrote:
> Although issuing a BINARY fetch for a non-terminal is obviously a SHOULD NOT, 
> I don't think it's a MUST NOT, and semantics must be defined. (It's 
> equivalent to a BODY fetch, because the CTE is always an identity one). My 
> reasoning here is that although it's pointless to do a BINARY fetch on a 
> non-terminal directly, some extensions have been proposed that internally 
> perform a binary fetch before performing some other operation. LZIP and 
> LCONVERT are defined like that, I believe.

I think that this is asking for trouble.

The addition of pointless capabilities causes certain individuals to 
assume, notwithstanding text in the specification to the contrary, that 
there is a point; what's more, they will infer the point.

We don't want to go there on non-terminal fetches.  I very reluctantly 
agreed to relax the restriction on a multipart fetch because there was a 
point to it (S/MIME handling) but I really don't want to go further down 
that slippery slope.

The problem with adding text to the specification is that people don't 
read the specification.  Just now, I am dealing with someone who doesn't 
have a clue as to what a literal is, yet is writing a server and asking 
"why is Outlook not working right" questions.

The more that we add unnecessary facilities (and bloat the specification 
as a result), the less that people will read the specification.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 22 Mar 2006 09:01:26 +0000

On Tue Mar 21 14:05:32 2006, Mark Crispin wrote:
> We don't want to go there on non-terminal fetches.  I very 
> reluctantly agreed to relax the restriction on a multipart fetch 
> because there was a point to it (S/MIME handling) but I really 
> don't want to go further down that slippery slope.

I'm not proposing we encourage it in any way, what I'm really angling 
for is that if another specification builds on BINARY internally, as 
LZIP and LCONVERT presently do, that these edge cases are better off 
being documented clearly, otherwise we run the risk of two 
specifications inadvertantly clashing when they require some kind of 
behaviour at the point.

I'm even okay with the behaviour not being available directly, as 
long as the nature of what a non-terminal looks like after 
transformation with BINARY is fully specified.

Dave.