On Fri, Jan 08, 2010 at 07:10:07PM +1100, Simon Horman wrote: > On Fri, Jan 08, 2010 at 03:18:05PM +1100, Russell Coker wrote: > > Package: perdition > > Version: 1.18-2.1 > > Severity: normal > > > > The list of valid capabilities differs between POP and IMAP, so it doesn't > > make > > sense to use the same config option for them. > > Good thinking. It should be pretty straight-forward to make > pop_capability and imap_capability separate and deprecate > capability. > > > Also the POP capability result returns all results on one line, which > > according to a brief skim read of the RFC appears to be invalid. So it > > would be good if the POP capabilities were converted from a single > > space-delimited line to multiple lines before returning the data to the > > client. > > Thanks for pointing that out, I'll fix it.
I'm scratching my head over how to make this work better. POP3 capabilities can include spaces. Or more specifically the capability may be followed by a space-delimited list of parameters. So rather than use a space to delimit capabilities, two spaces is used. So ---pop_capability "USER UIDL" works as expected. But ---pop_capability "USER UIDL" does not. Which seems to be all-together too subtle. An idea that I had was to allow multiple ---pop_capability arguments to be provided. e.g. ---pop_capability "USER" ---pop_capability "UIDL" This would probably work, though it might be a bit tricky to implement, just because of how the code is. But it would be doable. And it could be made backwards-compatibile - that is double-space delimited pop capabilities and single-space delimited imap capabilities could still be parsed and documented as deprecated. Another option, which is simpler from a coding point of view, would be to use . as the delimiter for POP3 capabilities. As "." is excluded from being used in capabilities (though perhaps not parameters). e.g. ---pop_capability "USER.UIDL.LOGIN-DELAY 900" But this seems less intuitive. Thoughts? BTW, are you really using POP3 capabilities? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
