Re: I want to add non-RFC passwd to pop and imap

[Sam Roberts]

Quoting Alain Magloire <address@hidden>, who wrote:
> > It *should* allow the password as in the other URLs, ftp, http,
> > etc., now you have to invent another syntax for fully specifying
> > the resource, and note that Mutt's mechanism is not general
> > enough, you have no way to specify which imap url the password
> > is associated with.
> 
> Unfortunately, the rationale and the wording of the RFCs
> were very clear.  But I certainly understand the point you
> are making and feel the same way.  So if you are proposing
> to allow in the URL passwd as an extension, I'm all for it
> if it does not break severly the current semantics in the
> RFCs.

I don't think it changes anything, unless you have a colon
in your user name, in which case you may be able to use pop
or imap, but better encode it when you try and ftp...

> > Also, I looked into the docs, cut the URL example out, and
> > compiled it. It doesn't do anything, sometime along the way
> > the URL parsing code got pulled out of url.c, and copied into
> > url_imap.c and url_pop.c. So, I pulled it back in, generalized
> > it, added this API:
> 
> This was done IIRC, because according to the rfc's each scheme
> is allowed to have whatever semantics after the "://", it does
> not have to follow the wellknown:
>  scheme :// user @ passwd / hostname : port / Query
> 
> Meaning it's not possible to come up with a general parsing algo
> for all schemes.  But in the cases that we are interrested;
> file:, pop:, imap:, mailto: They have enough similarities.

Yes, I noticed that there isn't a general syntax, but I think it's
close enough for the our purposes. I do a little checking after,
for instance pop checks that no path or query was specified after
the hostname. I think it's backwards compatible.


> > I'm cleaning up the docs to match the new API before committing. But
> 
> Wow!

And forgot the example .texi this morning, sorry!

Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)