ietf-mta-filters
[Top] [All Lists]

Re: Generalizing subaddress

2006-04-13 04:47:23

Aaron Stone wrote:

On Thu, 2006-04-06 at 18:48 +0100, Alexey Melnikov wrote:
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.

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.
Can you give an example of email address with detail1 and detail2?

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.
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.

Is there an extension for arrays perhaps? (or is it part of variables? I
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.



<Prev in Thread] Current Thread [Next in Thread>