# sequence numbers ( was: (long) sketch of proposed imap: URL syntax ... )

Steven D. Majewski (sdm7g@elvis.med.virginia.edu)
Wed, 6 Jul 1994 13:54:22 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mark Crispin: "Re: sequence numbers ( was: (long) sketch of proposed imap: URL syntax ... )"
- Previous message: David L Miller: "Re: (long) sketch of proposed imap: URL syntax and semantics"

    Date: Wed, 6 Jul 1994 13:54:22 -0400

    From: "Steven D. Majewski" <sdm7g@elvis.med.virginia.edu>

    Message-Id: <199407061754.AA13561@elvis.med.Virginia.EDU>

    To: David L Miller <dlm@cac.washington.edu>

    Subject: sequence numbers ( was: (long) sketch of proposed imap: URL syntax ... )

There hasn't been enough comment to reliably project a consensus, but
the early returns seem to soundly reject sequence numbers in an imap
URL.

I'm willing to deprecate it further, from "not recommended" to "for
internal use only". ( Again: does anyone know how to "lie" to the
client so that INTERNAL USE *stays* internal ? )

( and, in a previous message, I've backtracked somewhat on semantics
of mid: selector. )

JGM and I seem to be quite far apart in our views of the role of a URL.
I see the URL as a "resource locator", and imap as one possible *mechanism*
for fetching the referenced object.

On Jul 6, 11:35, John Gardiner Myers wrote:
>
> The IMAP protocol defines the format of the MIME structure
> information. You are proposing that this information when referenced
> by URL be in a different format than that designed by the IMAP
> developers. Thus, you are redesigning the IMAP protocol and you are
> giving no real reasons for doing so.
>

[ ... and other exchange on MIME body-parts and content id's snipped. ]

I am (repeat) NOT redesigning the IMAP protocol.

I was discussing questions of client presentation, on which the protocol
documents are silent.

The protocol defines what is returned by a FETCH BODY, or a FETCH RFC822
or any other fetch command. Nowhere is there a prescription that a
client must perform a FETCH RFC822 and display the entire contents if
a message is selected. Most reasonable MIME aware clients, would, I
think, decide to hide some messy stuff from user presentation. What
is displayed might even be user configurable. ( Pine's rich headers
ON/OFF for example. Or, from the Mosaic/WWW world, turning on/off
inline image display. )

Also note that a gateway ( in this case imap to http/html ) usually
does produce a "change in format", and that this particular
presentation decision may not be the same produced by a native mode
implementation.

This is obviously not my original position. I have been moved to
this current view by the discussion and objections you have raised.

My current position is:

Most of my discussion of semantics doesn't belong in any
definition of the URL standard.

Most of that discussion should be taken only as an example
describing how my gateway will interpret URL's. ( so that
a http client can display imap served messages. )

Other clients are free to make different presentation decisions.

What needs to be pinned down is: what object is pointed to by
a given URL ( and not how should that object be presented by
a user interface )

I will probably change the descibed semantics of mid:
selectors ( and query selectors ) so that if a single
message is found, that message will be displayed; if
multiple messages are found, then a list of messages
will be displayed. ( so that finding multiple messages
where you expect one is not an error )

-- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU> --
-- UVA Department of Molecular Physiology and Biological Physics --
-- Box 449 Health Science Center Charlottesville,VA 22908 --

- Next message: Mark Crispin: "Re: sequence numbers ( was: (long) sketch of proposed imap: URL syntax ... )"
- Previous message: David L Miller: "Re: (long) sketch of proposed imap: URL syntax and semantics"