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 <step...@xemacs.org>
> > >
> > >?
> >
> > ('Stephen J. Turnbull', 'step...@xemacs.org')
> >
> > 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:tonynel...@georgeanelson.com>
' <http://www.georgeanelson.com/>
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
