Subject: Re: Generalizing subaddress

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Apr 2006 18:48:16 +0100

Aaron Stone wrote:

>Now then, there's the more and more complex patterns... my suggestion is
>to accept a new fact:
>
>1.  There is always a "user" part, which refers to an account
>    in the email system.
>2.  There might be a "detail" part.
>3.  There might be a couple of detail parts.
>
# 3 is an interesting idea, but I think it is taking the idea of 
flexibility of this extension way too far.
The current document implies that all parts which are not "user" are in 
"detail".
A particular implementation can threat "detail" as a structured field, 
Sieve variables can be used to extract parts of it.

So let's keep the document the way it is.

[...]

>Thanks for reading if you got this far! I hope that my suggested change
>is well received. If not, forget that part and just remember that no
>matter what the subaddressing scheme is, there has to be some agreement
>between the email account lookup and the Sieve script about what parts
>of the subaddress are what in the mail system, and that implies at least
>a de-facto standard or contract of some kind among the codebases.
>
I agree with this part.

---

From: Aaron Stone <[email-masked]>
Date: Thu, 06 Apr 2006 11:47:19 -0700

> Sieve variables can be used to extract parts of it.

The problem I see with the current approach is that it violates the
"first normal form" from database theory -- which says each field should
be a single data type and not internally formatted -- thus requiring
that the script must have intimate knowledge of how the implementation
will format the "detail" part, and requiring other extensions to extract
that format into more readily usable parts.

Although my suggestion does require that the script knows the difference
between what's in "detail2" vs. "detail3", it's at least a little bit
abstract and can be more easily documented in the mail system's script
guidelines than a series of regex extractions into variables.

Is there an extension for arrays perhaps? (or is it part of variables? I
haven't looked recently...).

Aaron

---

From: Michael Haardt <[email-masked]>
Date: Thu, 6 Apr 2006 22:31:08 +0200

> flexibility of this extension way too far.

I thought of multiple detail parts, when I first suggested to have a
generic subaddress extension, but figured if people wanted to work with
such complexity, variables were most likely required, too.

A generic subaddress extension covers a large range of applications that
do not require variables, whereas multiple detail parts are used rarely,
often tied closely to specific software.  If anybody needs them urgently,
please speak up.  _I_ just need a generic subaddressing facility without
variables and with a single detail part urgently. ;-)

> Sieve variables can be used to extract parts of it.

Or a new extension that relies on variables could extract the detail parts
from the given address into variables, avoiding the structured field.  In
case someone decides it is worth writing a draft.

> So let's keep the document the way it is.

Agreed.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Apr 2006 23:06:58 +0100

>that format into more readily usable parts.
Can you give an example of email address with detail1 and detail2?

>guidelines than a series of regex extractions into variables.
I personally think that in order for detail2, detail3, etc. to be useful 
the WG needs to document what they mean. It is very very unlikely that 
we can agree on their semantics.

>haven't looked recently...).
There was no WG consensus to have arrays in the variables extension, but 
they can be added as a separate extension, if there is enough interest.