Re: API for Header objects [was: Dropping bytes "support" in json]

At 19:09 +0900 04/17/2009, Stephen J. Turnbull wrote:
>Tony Nelson writes:
>
> > No.  The useful data for an address field is *properly* a list of
> > pairs of friendly name, address -- you should read RFC 5322 section
> > 3.4.
>
>The fact that you think I didn't suggests there's really no point in
>continuing to talk to you.  But I'll give it another try.
>
>The issues we are dealing with at this point really have very little
>to do with accurate implementation of the RFCs.  We all know that's
>necessary, but ... it's a Simple Matter Of Programming.  At least,
>that's why Postel, Crocker, et al put so much effort into writing the
>RFCs, so it would be a SMOP.  I think they did a pretty good job.
>
>I agree with you that we should make it relatively difficult to put
>things that *don't* conform to the RFCs on the wire.  But that should
>be the responsibility of the middleware that talks to the file system
>and to the MTA.  I see no reason *at this stage* to burden MUA (in the
>general sense) developers with all the RFC rules, and MDA/MTA writers
>"should" only need to worry about it for error handling (__bytes__()
>should normally do the job for them).  (For values of "should"
>equivalent to "in my dreams", I do fear.)

You are insisting on is so burdening them.  I propose lifting that burden.


> > This makes it very important that the easy way of doing things be
> > the correct way.  With Address fields, that way is
>
>Nonsense.  You are ignoring the fact that *people* (ie, nobody
>participating in this thread<wink>) read an address field *as text*,
>and they type in addresses *as text*.  We do not extract and inject
>this information as pickles of Header objects via Firewire sockets
>implanted in their skulls.  There is *no /unique/ correct way* here.

If only "People" did that in a way that survived transport.

>
> > >For example (this is a trick question), in your opinion, what
> > >should
> > >
> > >    msg['To'][0]
> > >
> > >return if the original header was
> > >
> > >To: Stephen J. Turnbull <[email protected]>
> > >
> > >?
> >
> > ('Stephen J. Turnbull', '[email protected]')
> >
> > You must be very confused to think this is a trick question.
> > Try it with the current email package's email.utils.parseaddr().
> > Again, see RFC5322 section 3.4.
>
>But section 3.4 is not relevant to the trickiness, and parseaddr is
>not strictly conforming.  See the definitions of name-addr,
>display-name, phrase, word, atom, and atext in sections 3.2.3, 3.2.5,
>and 3.4 of the RFC you cite.  Also see the definition of special.
>Finally, I commend to your attention the definition of obs-phrase in
>section 4.1, and the *very* special nature of this particular gotcha
>as described there.

What parseaddr() doesn't support is groups.  I haven't seen groups used,
though.  It does support Comments when a name-addr is not present.

I still don't see any trick.  "Stephen J. Turnbull" has always been
accepted as a display-name, RFC 822 notwithstanding.  Any useful
implementation must take such things into account, even if conformance
would have required the display-name (or at least the ".") to have bee
quoted.


>The point is that by parsing that and claiming it's an RFC 5322
>section 3.4 name-addr, you have invoked the rather magical Postel
>Principle.  You either have to say "for my purpose I want magic in the
>API" (which you previously denied), or you have to admit that this is
>harder than it looks.
 ...

No.  You want to make it hard for the user of the email package.  I want to
make it easy for the user of the email package.  How hard it is for the
programmer is not an issue, but thank you for your concern.
-- 
____________________________________________________________________
TonyN.:'                       <mailto:[email protected]>
      '                              <http://www.georgeanelson.com/>