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

Re: Generalizing subaddress

2006-03-27 19:09:45


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

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