Re: draft-cadar-dhc-opt-imap-00
If the DHCP options are stored in a DHCP-specific config somewhere, and if your app has to fetch the options from that config in order to use them, then this kind of thing is not only harmless but is also pretty handy, since you can provide a user-config option that asks if they want to use DHCP or not. If so, fetch the data. If the DHCP client tries to update application-configuration data files directly (pushing the DHCP options out to your app), then this also means that somebody has modified the machine-wide DHCP client configuration with the path information to your app config file, meaning that somebody with privileges wants this to happen. If you use something like a DHCP mini-config file that the admin can point to, then you can also give the current user an option of using DHCP or some other configuration mechanism with a basic config option. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
while we're on the subject
A couple of observations and questions about folders and hierarchies: There are no mechanisms for manipulating hierarchies via the protocol. If I want to create or rename a folder hierarchy (eg, create a #public hierarchy), then I have to do it off-line since there is no support in the protocol directly. The largest addressable unit of data in the protocol is the folder, not the overall mailstore or its individual partitions that hold the different folders and hierarchies. Is this a weakness in the protocol, and should this support be added? Why do so many clients use LIST at the root of the namespace? Can't everything they need to discover about that level of the namespace be found with the NAMESPACE command, and wouldn't the NAMESPACE command be more efficient for what they hope to learn? I must be missing something obvious here, since the clear preference is for LIST. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
Re: while we're on the subject
On 1/6/2004 2:22 PM, Mark Crispin wrote: As far as creating namespaces themselves, these are usually an artifact of the implementation software and not a level of hierarchy. It may be helpful to think of namespaces as being like the D: and E: drives in Windows with the default namespace being the C: drive. Right, they are partitions of the underlying mailstore. The partitions may be tied to one or more filesystems, or they may be logical representations of a filesystem (eg, netnews) or some representation of a database subsystem, or whatever. It's perfectly valid for an implementation not to have any namespaces; think of UNIX which only has one filesystem. Usually. Remote filesystems can have different semantics in some cases (a DOS floppy, for example), although most of the time the filesystems are homogonized. With IMAP, the visible semantic differences tend to be in the separator syntaxes, such as a newsgroup partition having a different separator syntax than the personal partitions (even if the same filesystem is in use for both of them). Obviously I'm not telling anybody anything new here, but its also obvious that partitions are discrete units of data (they can even be queried for some attributes, but this is very limited functionality), and my feeling is that it would be useful to allow their management as such. The largest addressable unit of data in the protocol is the folder, not the overall mailstore or its individual partitions that hold the different folders and hierarchies. Is this a weakness in the protocol, and should this support be added? It's difficult to imagine how a protocol can manage creation of namespaces that refer to server based separate hierarchies. Either the server has netnews or it doesn't. Well, I don't see a lot of value in that particular example either, but that's lots of value in being able to create an #archives partition on the fly, assuming that the mailstore allows it. The use of special-strings for partition mapping is something separate, having more to do with the implementation than with the functionality I'm talking about. Servers like UW-IMAP don't have to be excluded here -- special-strings can be mapped, while undefined partitions can be rooted somewhere like /var/spool/imap -- but that's again product specific. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: while we're on the subject
On 1/6/2004 5:58 PM, Mark Crispin wrote: The barrier that your idea needs to overcome is why not use a root-level name instead of a namespace. To be clear, I'm not making a proposal. My original question was whether or not this is a hole in the protocol. Obviously it's not a very big hole or else it would have been filled already. To answer your question though, there are a lot of operational benefits to dynamic partitions. An obvious benefit is that partitioning simplifies replication. Another benefit is that it allows you to use alternative storage mechanisms, like maybe putting a partition on a CD-RW drive, and only bothering to make it available when you need to access it (this is what I was thinking about with the #Archive thing). Some of the more mundaine benefits are already well known (that's why servers offer the off-line mechanisms that they do have, because they are valuable). The only real question is whether or not there would be more or less value in providing in-band mechanisms for this stuff. In the general case, I think that having folder-managemenet tools available (eg, ACL widgets) would be useful for partitions, although the frequency of such usages may be suspect. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: while we're on the subject
On 1/6/2004 8:39 PM, Tim Showalter wrote: It's not necessary that partitions should map to NAMESPACE-advertised parts hierarchy at all. Cyrus allows mailboxes in the same hierarchy to live on different partitions. I see what you're saying, but I think that level of abstraction is also somewhere else entirely -- mailstore partitions built on top of (product-specific) database partitions is an interesting architectural discussion point, but maybe shouldn't be a design constraint anymore than an overly-rigid filesystem mapping should be a design constraint. Or was there something more to the statement that I missed? I can see why you might want filesystems and mailbox hierarchies to coincide I don't want that explicitly, but where a specific server architecture uses such an architecture, then the benefit is there for the mentioning as an example. In the case of Exchange (as an opposite architecture, but with the same potential) using mailstore partitions would also facilitate some kinds of replication and near-line storage mechanisms, albeit with much greater effort. Really I'm just trying to figure out how useful it would be to have partitions be full-fledged data-objects in IMAP. They are only partial citizens right now, with just a couple of attributes and not much in the way of management knobs and buttons. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: IMAP not good enough?
on 8/15/2003 11:37 AM Larry Osterman wrote: Ok, mine agrees with mine :) http://dictionary.reference.com/search?q=protocol pro·to·col( P ) Pronunciation Key (prt-kôl, -kl, -kl) n. Computer Science. A standard procedure for regulating data transmission between computers. procedure is the key, not format also see http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=protocolaction=Search protocol A set of formal rules describing how to transmit data, especially across a network. Low level protocols define the electrical and physical standards to be observed, bit- and byte-ordering and the transmission and error detection and correction of the bit stream. High level protocols deal with the data formatting, including the syntax of messages, the terminal to computer dialogue, character sets, sequencing of messages etc. Many protocols are defined by RFCs or by OSI. See also handshaking. [Jargon File] (1995-01-12) -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
1731, loose end
Just noticed a trivial loose-end, but one which should be fixed. Specifically, RFC 1731 isn't formally deprecated nor was it obsoleted by RFC . However, since RFC 3501 explicitly references now, 1731 should probably be snipped out of the standards-track document set by some kind of administrative action. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html -
Re: adult and spam/junk keywords (was Re: I-DACTION:draft-melnikov-imap-keywords-01.txt)
on 7/11/2003 1:13 PM Cyrus Daboo wrote: pick another character at the start, e.g. '%' and say that corresponds to a registered vendor space, without having to have 'vendor' at the start of the keyword. My only comment here is that I would prefer to see OIDs instead of vendor names. Products change hands, some flags are designed to be used by multiple products from the start, etc., and OIDs provide a natural way of virtualizing identifiers while still preserving clear lines of authority. The use of a special character makes sense to me. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Message flag caching and polling.
on 3/12/2003 2:42 AM David Woodhouse wrote: On Wed, 2003-03-12 at 06:58, Eric A. Hall wrote: I'm not trying to start a religious war here, but how much work would it really be to have a protocol extension which allowed the client to request flags which have changed since time. It seems that all of the difficulty would be in the implementation (the server data-store), not in the protocol, and there would be significant benefits to having this option available in the protocol. Faster resynchronization between sessions would be very good for all clients, online and offline alike. I'm going to assume you meant something sane when you said time, of course :) Uh, heh, I meant time alright. Specifically have the server return a timestamp whenever a folder is closed, and let the client cache it. On reconnect, the client can just ask for all messages with a modification timestamp later than the last-cached value for that folder. For rich data-stores, this just requires a last-modified-on attribute for each message record; return those records which have a last-modified-on value greater than the requested value. The protocol side could be fairly simple -- the idea that Timo Sirainen offered in [EMAIL PROTECTED] seems fairly close to what we'd want. You'd declare that a server supporting FLAGS-VALIDITY _MUST_ include any messages with changed flags in its response, and SHOULD make an effort not to include messages _without_ changed flags. Doesn't this require the server to cache client state? It'd be a lot simpler for the clients to keep track of their own state, since that's what they're already doing. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Message flag caching and polling.
on 3/12/2003 5:38 PM Steve Hole wrote: The answer -- the bigger the mailbox and the lower the transaction rate into the mailbox, the bigger the win. If the mailbox was small or had a high transaction rate (lots of expunged and new messages) then it wasn't that much of a win. A number of mailboxes do have this type of activity pattern -- my inbox being one of those. That seems like a reasonable outcome if you are only taking watermarks periodically. If the watermark was updated frequently (such as each open and close), wouldn't the problem be diminished for mailboxes that were selected frequently? Also the obvious point that where this feature benefits the most is exactly where it is needed the most. I have more than a few folders with 4000 messages in them, and those folders take a very long time to open whenever there is any significant latency or bandwidth constraint. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: Message flag caching and polling.
on 3/11/2003 4:56 PM Mark Crispin wrote: Have you noticed that Pine *does* completely cache within a session? As long as you don't give up the session, Pine will never re-fetch the same data. I'm not trying to start a religious war here, but how much work would it really be to have a protocol extension which allowed the client to request flags which have changed since time. It seems that all of the difficulty would be in the implementation (the server data-store), not in the protocol, and there would be significant benefits to having this option available in the protocol. Faster resynchronization between sessions would be very good for all clients, online and offline alike. In those cases where it was impractical to store this kind of information, the server wouldn't implement it, which is reasonable behavior for any optional extension. Ignoring the data-store issues which will dictate whether a specific server is able to implement the feature, how feasible would this be? -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: How to unsubscribe
on 10/10/2002 10:17 AM Marek Kowal wrote: Oh, by the way, since we already talk about the list itself... what content filter should I set up so that I am 100% sure, that it will match _ALL_ the messages from this list and direct them to specific folder? The Sender: header field is usually the best for this, although technically it should never be rewritten by mailing list exploders, and should therefore technically not function for this purpose (but it is usually the best regardless of all that). If a mailing list includes any of the List-* header fields, use one of those instead. List-Post: mailto:imap;u.washington.edu looks like a pretty good candidate. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
