Re: RFC 822 address parsingu

[Alain Magloire]

Bonjour

: Since the address-list may contain multiple addresses, they are accessed
: by a @strong{one-based index number}, @var{no}.
: 
: Comment: Why is this one-based? nobody
: familiar with C would ever expect that!

To be consistent whith mailbox_get_message().  Message are one-based count.
Most protocol (IMAP) etc .. use one base count, the first message is 
msg number 1.  The library takes care of mapping it to whatever forms/index 
it uses.

: The API isn't complete, there are useful things you can't do.

Agreed.  This was the first draft to come up with some usefull API.
For clients __and__ server.

: There needs to be a way of accessing the local-part and the
: domain of an email address seperately, the syntax of local-part
: is too complex
: to expect somebody to parse it, in particular strchring for '@@'
: will fail if there is an '@@' in the local-part, which is valid if
: its quoted or escaped.

Good point.  I did not go that far, what do you suggest?  I know there
is work underway for a new RFC822, maybe it should follow this direction.

: You can't create an address or an address list.

Maybe  I'm missing something here, but :
{
  address_t add;
  address_create (&add, "address@hidden, address@hidden");
}

: What about groups? They are easy to parse, but a pain from an api point
: of view. _address, instead of being a pure linked list, could

Groups was not "address" in the first API.
One of the problem, is group can sometimes be confuse with "aliases" that
Mail clients have.  They use it in address book to maintain a list of
email address.  They propably don't want to have the "group:" name part
of the final address.

So are you suggesting to have a special object say :
address_group_t or address_alias_t
that would let client regroup in simple aliases mail address?

: // -1 is the end, anything else is position to be inserted at, for ex.
: address_create(&group, NULL)
: address_insert(group, -1, "Sam", "sroberts", "uniserve.com");
: address_insert(group, -1, "Joe @ \"home\"", "joe", "uniserve.com");
: address_insert_group(addr, group, "the uniserve boys");

Again your example is not clear(to me 8), do you mean

group_t group;
group_create(&group, NULL)
group_insert(group, -1, "Sam", "sroberts", "uniserve.com");
group_insert(group, -1, "Joe @ \"home\"", "joe", "uniserve.com");

// For an already constructed address_t.
// To bad no overloading in C.
address_t add;
....
group_insert_address (group, addr);

Note:  for the -1 hack how about a cover function :

group_append (group_t group, char *s1, char *s2, char *s3)
{
  return group_insert (group, -1, s1, s2, s3);
} 

: and utf-8 in the strings, just allow it? The machinery to encode
: and decode header fields according to the MIME spec doesn't really
: belong here, it's a layer on top of rfc822.

I disagree.  We have two objects header_t and addresss_t.
header_t is dumb just extract the rfc822 :

field-name: field-value
[ space ] field-value2

and let you set/get it via :

header_get_value (header, value, ....)
header_set_value (header, value, ....)

header_get_value (header, "From", buffer ...);
buffer will contian "(joe the man) address@hidden".

Nothing more is done.

Adress_t is more complex, parsing is done.

The address_t can take one more method encode()/decode (), not sure
on the API/prototypes.  When set, things like.

=?ISO-8859-1?Q?Fran=E7ois_Pinard?= <address@hidden>

Will be map back properly when retreiving the info:

address_get_personal (add, pos, buffer, ... )

The same should be true for the reverse.

(where "c," is cedilla i.e. a char over ascii 7 bits.)
address_set_personal (add, "Franc,ois Pinard")
--> =?ISO-8859-1?Q?Fran=E7ois_Pinard?=

It should be made clearrer the distinction between
header_t and address_t etc ...

: Simple things should still be simple.

Speaking with my heart.

--
alain