[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generalizing subaddress
> >I was tasked at Tuesday's Sieve WG meeting with trying to make the
> >language in the subaddress draft even more general than it
> >currently is, but as Philip noted in another thread, doing so makes
> >it very difficult to describe when :detail is present/empty/not
> >present. I have not found a way to describe these states without
> >relying on some type of 'delimiter' or 'separator'.
If the encoding of a detail depends on the target address, determining
if it contains no, an empty or a non-empty detail part depends on the
target address, too. It can not be described in the subaddress extension.
I suggest:
The ":detail" argument specifies the detail sub-part of the local-part
of an address. The encoding of the detail sub-part is dependent on
the encompassing mail system and recipient address. If the recipient
address is not encoded to contain a detail part, the test evaluates
to false. An encoded empty detail information causes an empty key
("").
Something sounds wrong there, but a native speaker can certainly fix it.
> I think much of Ken's problem here is that he's trying to build a
> standard method for doing something with unstandardized local part
> formats.
Exactly.
> Perhaps what's actually needed is some kind of informational document
> describing various mechanisms that exist for subaddressing and
> similar local-part "encodings", and then using the subaddress Sieve
> extension to access those encodings.
I agree, although I would like to keep that purely informational and allow
the extension to make use of methods not described in such a document.
Yet it may reduce the amount of new encoding schemes arising just because
people never saw existing approaches to the problem.
Michael