home *** CD-ROM | disk | FTP | other *** search
- First, thank you to Mark Crispin for creating this list!
-
- I'd like to ask what work is under way, or planned, for the next version
- of IMAP2. In particular, are there plans for protocol support for:
-
- 1. access to the host's quota control mechanism, where one exists
- 2. password changing (for non-Kerberos sites)
- 3. forwarding (automatic, i.e. access to '.forward' file or equivalent)
- ...
- 4. simple X.500 interface
- 5. forwarding (user-initiated, i.e. in a session)
- 6. mail sending
-
- (in decreasing order of importance - gap indicates where 'really needed'
- changes to 'would be nice'). I can provide arguments for each of those on
- request, and could probably work out upwards-compatible protocol
- extensions, but I thought I'd check first to see if anyone else agrees. I
- realise not all servers will want to / be able to provide any of these
- functions, but many host systems can do, and it would be better to have
- standardised protocol extensions rather than everyone inventing their own.
- In particular, we see access to quota control (i.e. simply finding out what
- percentage of quota has been used) as essential for naive users, since the
- consequences of exceeding quotas can be utterly confusing.
- --
- Alasdair Grant +44 223 334447
- MVS Systems Group / Small Systems Integration Group
- University Computing Service, A.Grant@ucs.cam.ac.uk
- Pembroke St., Cambridge CB2 3QG, UK
- From imap-request@cac.washington.edu Tue Sep 1 14:07:18 1992
- Received: from mx1.cac.washington.edu by akbar.cac.washington.edu
- (5.65/UW-NDC Revision: 2.27 ) id AA12245; Tue, 1 Sep 92 14:07:18 -0700
- Received: by mx1.cac.washington.edu
- (5.65/UW-NDC Revision: 2.27 ) id AA29395; Tue, 1 Sep 92 14:07:14 -0700
- Errors-To: imap-request@cac.washington.edu
- Sender: imap-request@cac.washington.edu
- Received: from tomobiki-cho.cac.washington.edu by mx1.cac.washington.edu
- (5.65/UW-NDC Revision: 2.27 ) id AA29389; Tue, 1 Sep 92 14:07:12 -0700
- Date: Tue, 1 Sep 1992 13:38:30 -0700 (PDT)
- From: Mark Crispin <MRC@CAC.Washington.EDU>
- Subject: re: IMAP2 futures?
- To: IMAP Interest List <IMAP@CAC.Washington.EDU>
- Message-Id: <MailManager.715379910.19965.mrc@Tomobiki-Cho.CAC.Washington.EDU>
- Mime-Version: 1.0
- Content-Type: TEXT/PLAIN; charset=US-ASCII
-
- You raise a number of interesting questions:
-
- > 1. access to the host's quota control mechanism, where one exists
-
- This is difficult to do in any sort of general way. One problem is that
- different implementations have different interpretations of quotas.
-
- On many systems, a quota is really some number of disk records (or clusters of
- disk records). Users often don't know their real quota; they are told some
- number of `bytes' or `blocks' but they discover -- to their confusion -- that
- they are out of quota even though the total number of `bytes' or `blocks' is
- considerably less.
-
- [Anecdote: A system I used 19 years ago gave users a `100 block' quota, saying
- this was 64,000 characters. However, it actually allocated (and charged!) in
- clusters of 5 blocks, so the actual limit was 20 files, and only if the files
- were less than 3200 characters each -- a 3201 character file was charged as 10
- blocks.]
-
- I agree that some mechanism to give users a handle on their disk quota
- remotely is necessary. It is important that any mechanism picked *not* be
- biased towards on particular operating system's strategy, and that the data be
- useful for a user. Another issue is scoping; IMAP must not be allowed to get
- `everything but the kitchen sink' put in, or we'll end up with an unwieldy
- mess. This is one reason why only minimal management was put into IMAP2bis
- and why the more complex management issues were deferred to the Mail
- Management Protocol.
-
- So, let's put this on the table as a topic.
-
- Modern-day c-client does detect and clean up properly when quota problems hit.
-
- > 2. password changing (for non-Kerberos sites)
-
- I believe that this was going to be considered as part of the Mail Management
- Protocol developed by CMU. I'd like to hear comments from the CMU hackers on
- this. I think that an environment in which users do not log into the IMAP
- server as timesharing users will have to have the Mail Management Protocol
- layer; the IMAP-only environment is for the `simple' configurations.
-
- > 3. forwarding (automatic, i.e. access to '.forward' file or equivalent)
-
- This is also a Mail Management Protocol issue for the same reasons. CMU???
-
- > 4. simple X.500 interface
-
- This is one of those things that everyone talks about a lot, but it isn't all
- that clear to me what it implies. X.500 is supposed to solve all our problems
- but then again X.400 was supposed to do so too. I don't think that `simple'
- and `X.anything' properly go together. We'll need to do something about this,
- but I'm taking a `wait and see' attitude until I understand the issues better.
-
- > 5. forwarding (user-initiated, i.e. in a session)
-
- Could you explain this? I don't quite understand what you mean. Do you mean
- forwarding a message or altering your mail forwarding or ??
-
- > 6. mail sending
-
- This is a frequently asked request. The IETF-REMMAIL group seems to have
- sputtered out on this question, without achieving closure. There are strong
- arguments on both sides of the issue. Although I am an `anti', I am
- sympathetic to the problems the `pro' side faces; however, I have been totally
- unsuccessful in playing Devil's Advocate for the `pro' side.
-
- I suggest a review of the IETF-REMMAIL@UMich.EDU discussion to avoid rehashing
- the same points over again. It's an emotional topic; the `pro' side is
- defending what they consider to be the side of simplicity (of a sort) and
- authentication (again, of a sort), while the `anti' side defends simplicity
- (of a different sort) and models which are possible only if mail access and
- mail posting are not coupled.
-
- If possible, I would like to see the discussion of this topic take place on
- IETF-REMMAIL and not here. I am agreeable to letting IMAP follow the
- concensus of the IETF-REMMAIL group, should they achieve closure on the topic.
-
- -- Mark --
-
-