Re: group name support, and some bug, test suite, and doc patches

[Alain Magloire]

> 
> Ok, this isn't exactly what we talked about, Alain, so if it don't work
> for you tell me, however I looked at the draft for the msg format RFC,
> and they put it the way I thought it should be, namely the group
> name is equivalent to the personal name:
> 
> name-addr = [display-name] "<" addr-spec ">"
> group     = display-name ":" [mailbox-list] ";"
> 
> So either way display-name is a "displayable" name for either a
> single address, or a group of addresses. Thus, group name gets stuffed
> in personal, and local_part, domain, and email for that "address" will
> be zero-length (or you can use the handy address_is_group() to see
> if this is the "personal" name of a group.

Ok.  We can live with this.
And frankly I do not see any other good alternatives.  It suprises
me that IMAP4V1 RFC2060 would consider the group name as the local_part
field(see rfc2060 the BNF syntax for address list)  and in any case probably
too late to change the behaviour even in IMAPV.

> 
> The attached Addrs.good is used by the test, and should go in examples/.

Done.

> I also added my tests to examples, it's not what you'd call sophisticated,
> but it does provide examples of how addresses should be parsed by
> address_create().
> 
> Sam
> 
> p.s. Take a peek at the "to consider" in parse822.c. The API has some
> wrinkles. Cheers, dinner time for this boy!

Good questions, and I do not have anything intelligent to say.
Buf for:
 - parse field names and bodies?

Interresting, that may force me to revisit header_t(header.c) and use
parse822 as the underlying engine.

  - parse dates?

Very usefull for IMAP and for clients in general when sorting by date.

  - parse Received: field?

Yes an interesting challenge.  You'll have to come up with some AI
parser ;-) to come up with all the crap that mail servers are stuffing
in this field.

> 
> p.p.s. I don't know if you have a test suite, but I've a collection of
> odd messages I've received, and also I note that drums has a number
> of example messages in it's back, might be a useful test
> for the message parsing code. I might put it all into an mbox file.

Good idea.

> +2001-04-14  Sam Roberts
> +     * examples/{Makefile,Addrs,addr.c,Addrs.good}: address test f/w.
> +     * include/mailutils/address.h,mailbox/{address.c,parse822.c}: now
> +       stuff a group name into an _address, and added a function to do
> +       a quick check if it is a group.
> +     * mailbox/parse822.c: fixed bug where ",address@hidden" wasn't valid.
> +

Thanks patch applied.


--
alain