On Fri, 2006-03-24 at 15:47 +0100, Michael Haardt wrote:
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
("").
I suggest changing the last sentence to something like 'An encoded empty
detail sub-part will product the empty key value ("").'
Something sounds wrong there, but a native speaker can certainly fix it.
sounds good to me, but I'm not a native speaker, either :-) I assume
you mean the "Note" following the paragraph should be removed, too.
the introduction needs to be made less explicit, it says:
. Introduction
Subaddressing is the practice of augmenting (usually with a suffix)
the local-part of an [RFC2822] address with some "detail" information
to indicate that the message should be delivered to the mailbox
specified by the "detail" information. A "separator character
sequence" (typically "+"), forms the boundary between the "user"
(original local-part) and "detail" sub-parts of the address, much
like the "@" character forms the boundary between the local-part and
domain.
I suggest to change the last sentence:
One common way of encoding "detail" information is to add a
"separator character sequence", for instance "+", to form a
boundary between the "user" (original local-part) and "detail"
sub-parts [...]
the examples are fine, but a more "esoteric" example would be nice. I
suggest BATV as an informative reference. it only applies to bounce
messages, of course (since a remote recipient can't decode it), but it's
an example of an opaque encoding with information which could be
presented to the user through this extension if the server administrator
chooses to.
I have to say I'm not wild about using system-level examples in this
context. As I tried to point out at the meeting last week, the intent
behind this extension is to provide a means for users to extract subaddress
information from their addresses in a portable way. It isn't clear to me
it is appropriate to use this mechanism for BATV, or SRS, or anything
similar, so I'm hesitant to have examples of such usage.
Ned