[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