Subject: Re: Annotations: alternate data model
From: Tony Hansen <[email-masked]>
To: John Haxby <[email-masked]>
Cc: [email-masked]
Date: Wed, 28 Jul 1999 21:05:42 -0400

John Haxby wrote:
> 
> > Non-validating XML parsers are fairly cheap to implement and are freely
> > available.
> 
> Could you provide some pointers to these freely available parsers?

Some free parsers are available at:

	http://www.w3.org/Library/		non-validating (C)
	http://www.alphaworks.ibm.com/		validating (C++,Java)

	Tony Hansen
	[email-masked]

Date: Wed, 28 Jul 1999 16:30:25 +0100
From: John Haxby <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------914A13F32093D2B4108DB02C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

> Non-validating XML parsers are fairly cheap to implement and are freely
> available.

Could you provide some pointers to these freely available parsers?

>
> I've been using XML in some projects here and like a lot of its
> features. We did have to do something about representing binary values
> within XML, but otherwise are fairly pleased with XML as a data
> representation language.

I have to agree here.

It's certainly a lot easier to get to grips with than ASN.1!

jch

--------------914A13F32093D2B4108DB02C
Content-Type: text/x-vcard; charset=us-ascii;
 name="jch.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Haxby
Content-Disposition: attachment;
 filename="jch.vcf"

begin:vcard 
n:Haxby;John
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:http://www.hp.com/go/OpenMail
org:Hewlett Packard;OpenMail R&D<img src="http://www.ice.hp.com/cyc/om/50/graphics/omlinux.jpg" width=53 height=62 align=top>
adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;14976
fn:John Haxby
end:vcard

--------------914A13F32093D2B4108DB02C--

Date: Wed, 28 Jul 1999 09:57:03 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
CC: John Stracke <[email-masked]>
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> > The strawman annotation model that was presented suggested a basic
> > name/value data model, but also mentioned the possibility of wanting to
> > permit values to be large binary blobs.  Rather than develop a new
> > syntax for doing this, you might want to adopt something like the WebDAV
> > property model, in which a property is an XML element.  The name of the
> > element becomes the name of the property, and you get to use all the
> > features of XML (structured data, internationalization, namespaces,
> > etc.).
> 
> I had another look at the WebDAV RFC after your comments and there are some
> interesting things there that could be applied to ANNOTATE. But...
> 
> > (Of course, this may not make as much sense in IMAP as in WebDAV, where
> > most of the protocol information is carried in XML in the first place.)
> 
> This is the issue. WebDAV has everything wrapped up in an XML document. It
> requires XML parsers on both the server and client. I'm not sure we want to
> lay this burden on IMAP servers and clients.
> 
> Though not being a WebDAV/XML expert I'm certainly open to suggestions as
> to how this might be applied to ANNOTATE.

Non-validating XML parsers are fairly cheap to implement and are freely
available. You're going to have to have a parser anyway, and an XML
parser isn't overly harder than a parser for any other data
representation language.

I've been using XML in some projects here and like a lot of its
features. We did have to do something about representing binary values
within XML, but otherwise are fairly pleased with XML as a data
representation language.

	Tony Hansen
	[email-masked]

Date: Fri, 23 Jul 1999 15:49:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>, Barry Leiba <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Subject: Re: per-part message flags (was: Oslo WG meeting notes)
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Fri, Jul 23, 1999 1:11 PM -0600 Steve Hole
<[email-masked]> wrote:

> In fact, with some clever thinking we might be able to allow scoping 
> management to be explicit, and have the standard per-message flags
> exposed  as part of the annotation data.   In that way we could expose
> the standard  system flags to the explicit scoping management.   That way
> systems that  support shared folders can allow the application to specify
> the scoping  for flags on messages in the folder.   Call center
> management, help desk  applications etc have wanted this capability for
> awhile.   Don't know if I want to write that, but it would be cool.

I'm reluctant to expose any existing IMAP data through the annotation
mechanism (e.g. having an annotation that returns the current set of
message flags or the ENVELOPE etc). Since there's already a way to get to
this data there's no need for it in an annotation.

What you're proposing above is more of a redifinition of the existing flags
and I think that should be handled as a completely separate annotation
mechanism rather than being tied to the existing IMAP flags.

--
Cyrus

From: Steve Hole <[email-masked]>
Date: Fri, 23 Jul 1999 13:11:12 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: per-part message flags (was: Oslo WG meeting notes)
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999 14:11:56 -0400 Barry Leiba <[email-masked]> 
wrote:

> Just as we have the issue of per-user and global message flags, we have 
> the 
> same issue of per-user and global annotations.  Except, unlike with message
> flags, I think we must answer the question explicitly.  That is, I think we
> must provide a definitive answer to the question of whether a particular
> annotation is user-specific or global.  Otherwise we'll have an interoperability
> disaster.

You're right, we must.   

** Begin semi-serious hypothesizing **

In fact, with some clever thinking we might be able to allow scoping 
management to be explicit, and have the standard per-message flags exposed 
as part of the annotation data.   In that way we could expose the standard 
system flags to the explicit scoping management.   That way systems that 
support shared folders can allow the application to specify the scoping 
for flags on messages in the folder.   Call center management, help desk 
applications etc have wanted this capability for awhile.   Don't know if I
want to write that, but it would be cool.

** End semi-serious hypothesizing **

Cheers.   

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 23 Jul 1999 14:11:56 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: per-part message flags (was: Oslo WG meeting notes)
Sender: [email-masked]

> but soon). There will be an annotation 'hierarchy' that mimics the
> bodystructure of the message thus allowing per-part annotations. A 'flags'
> entry could then be defined in the spec with well-defined syntax for doing

Yes, that'd be perfect; I hadn't thought the ANNOTATE extension was going 
to have (effectively) per-part annotations.  Sure, with annotations, a flag 
just becomes a special case.

> per-part flags. Of course there is a major problem of how to handle
> per-user per-part flags for shared mailboxes and that's going to require

Just as we have the issue of per-user and global message flags, we have the 
same issue of per-user and global annotations.  Except, unlike with message
flags, I think we must answer the question explicitly.  That is, I think we
must provide a definitive answer to the question of whether a particular
annotation is user-specific or global.  Otherwise we'll have an interoperability
disaster.

Evil Barry, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Fri, 23 Jul 1999 08:43:03 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re:  per-part message flags (was: Oslo WG meeting notes)
Cc: Barry Leiba <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999 10:38:21 -0400 Cyrus Daboo <[email-masked]> wrote:

> Of course there is a major problem of how to handle
> per-user per-part flags for shared mailboxes and that's going to require
> some careful design.

That's why Barry is evil :-)   Actually, Barry's not evil, he's quite a 
nice guy.   Just his ideas are evil.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 23 Jul 1999 10:38:21 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>, Barry Leiba <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Subject: Re:  per-part message flags (was: Oslo WG meeting notes)
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Fri, Jul 23, 1999 8:22 AM -0600 Steve Hole
<[email-masked]> wrote:

> There are certainly applications for per-part flags.   If I implement 
> annotations, a general mechanism for per-message metadata, then I'm not 
> keen to do this as another extension as well.   It is arguable that 
> annotations would be more difficult to implement, but I'm not sure that 
> that is true -- at least for our server.   I have a hard time thinking of 
> the architecture of other servers, so I admit that similarity of 
> implementation may not be true for other servers.    When I think about 
> how to do either of these things in our server, ANNOTATE is only slightly 
> harder than per-part flags, but is much more flexible and general.
> 
> If we wanted to do this, I would propose some kind of profiled use of 
> ANNOTATE.   Much like the "standard options" in the ACAP Options dataset 
> class.

That's indeed what I'm planning on including in the first cut of the
ANNOTATE draft that Randy and I are working on (well he's not seen it yet -
but soon). There will be an annotation 'hierarchy' that mimics the
bodystructure of the message thus allowing per-part annotations. A 'flags'
entry could then be defined in the spec with well-defined syntax for doing
per-part flags. Of course there is a major problem of how to handle
per-user per-part flags for shared mailboxes and that's going to require
some careful design.

--
Cyrus

From: Steve Hole <[email-masked]>
Date: Fri, 23 Jul 1999 08:22:15 -0600
To: Barry Leiba <[email-masked]>
Subject: Re:  per-part message flags (was: Oslo WG meeting notes)
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999 08:49:48 -0400 Barry Leiba <[email-masked]> 
wrote:

> OTOH, I don't see a reason not to have "part flags", just as we have 
> folder flags and message flags.  This is distinct from the need for
> annotations.  I can see several uses for part flags.  For instance,
> suppose you send me 10 presentation slides, as 10 separate JPEG images.
> I might want to flag the one with a particular pie chart as "\flagged",
> because it's the one that's especially interesting to me.  I also might
> want to know which of the JPEG images I've "\seen" and which I haven't, 
> as I'm poking my way through your presentation.

You are an evil, evil man :-)    

There are certainly applications for per-part flags.   If I implement 
annotations, a general mechanism for per-message metadata, then I'm not 
keen to do this as another extension as well.   It is arguable that 
annotations would be more difficult to implement, but I'm not sure that 
that is true -- at least for our server.   I have a hard time thinking of 
the architecture of other servers, so I admit that similarity of 
implementation may not be true for other servers.    When I think about 
how to do either of these things in our server, ANNOTATE is only slightly 
harder than per-part flags, but is much more flexible and general.

If we wanted to do this, I would propose some kind of profiled use of 
ANNOTATE.   Much like the "standard options" in the ACAP Options dataset 
class.

Cheers.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 23 Jul 1999 08:49:48 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: Oslo WG meeting notes
Sender: [email-masked]

Steve, thanks for the summary, and thanks also to Alexey and Nick,
who filled me in offline.

> > > *** Transcoding Request
> > > - assertion that there are substantial interoperability issues
> > > - better dealt with by picking standardized represention of content-type
> 
> The concensus was that expecting servers to implement elaborate
> transcoding facilities, it would be much better if the VPIM folks could
> settle on a reasonable small set of mandatory or recommended to implement.

I agree with that as far as it goes, except that it only applies to the
case of using transcoding with VPIM, and that it assumes that every
device is able to implement the mandatory set.

When we first started talking about transcoding, I saw it (and still see
it) as a way to, say, ask for an image in a different format, to ask for
a video with fewer frames, to ask for an OCR analysis of a fax, and stuff
like that.  Suppose I have a handheld that does 256 colours on a 200x200
screen.  It does me little good to transfer a 1024x768 image with 64K 
colours.  WIBNI I could ask the server (assuming support; yes, this is a
nasty issue) to convert the image to something I could use, which wouldn't
take so long to download over my cellular link that's giving me an effective
transfer rate of only a few hundred bytes per second?

Maybe you sent me a fax of a brochure, with lots of pictures and some text.
What I need right now are the details of the conference -- dates, location,
topics.  I don't need to see the fax image; I want it put through OCR and
I want to get the results as text on my handheld.  Cool.

I think it's useful to have such capability, and I think it's worth discussing
how we might do it in an interoperable way.  The tough bits will be defining
the various transcodings that can be done, how to list them, how to specify
them, how to add more, and so on.  The basic mechanism shouldn't be terribly
controversial.

> > > *** Message length indication
...
> VPIM would like to have an indication of the length of a part in other
> units ie. seconds for sound, pages for fax etc. 

Ah, right; I didn't recognize it from the name.  I remember some discussions
about that.

> have anything to do with IMAP *except* that it is yet another new
> Content-{mumble} header that is a pain in the ass to retrieve via IMAP.

Yeah, this, though, is something we *should* work on: a better, more easily 
extended way to return the content-xxx headers.  The problem is that a client
has to "fetch bodystructure", figure out all the part IDs, and then fetch
"body[1.2.5.mime]" for each part.  Or we have to extend the bodystructure
response for each new item, and that gets icky fast.

My colleague, Wolfgang Segmuller, had once proposed having a "fetch mimestructure"
sort of thing, which parallels the bodystructure but which returns all the
mime headers for the parts in the same way that, say, content-type parameters
are returned now.  So "fetch bodystructure" returns a set of nested, parenthesized
part descriptors, and "fetch mimestructure" would return a set of similarly
nested, parenthesized part header-lists.

> > > *** Body part read indication
... 
> The requirement itself was called into question.   The premise for the
> requirement was that one body part was the "distinguished" body part of
> the message and reading it really indicates that the message has been
> "seen" by the user. 

Ah, right... from that aspect I agree.

OTOH, I don't see a reason not to have "part flags", just as we have 
folder flags and message flags.  This is distinct from the need for
annotations.  I can see several uses for part flags.  For instance,
suppose you send me 10 presentation slides, as 10 separate JPEG images.
I might want to flag the one with a particular pie chart as "\flagged",
because it's the one that's especially interesting to me.  I also might
want to know which of the JPEG images I've "\seen" and which I haven't, 
as I'm poking my way through your presentation.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Thu, 22 Jul 1999 15:08:10 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: Oslo WG meeting notes
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

Woops ... sorry Barry, I tuned out there for a second.   Looked at the 
wrong mailing list.

On Tue, 20 Jul 1999 09:20:39 -0400 Barry Leiba <[email-masked]> 
wrote:

> There are a few items here that are sufficiently brief that I'd like a 
> bit more information.
> 
> > *** Transcoding Request
> > - assertion that there are substantial interoperability issues
> > - better dealt with by picking standardized represention of content-type

The concensus was that expecting servers to implement elaborate 
transcoding facilities, it would be much better if the VPIM folks could 
settle on a reasonable small set of mandatory or recommended to implement.
I offer no opinion on whether this is a valid view or not, I simply 
summarize the conversation.

> > *** Message length indication
> > - assertion that this is not an IMAP issue - it is MIME issue
> 
> What *is* this issue?

VPIM would like to have an indication of the length of a part in other 
units ie. seconds for sound, pages for fax etc.   We simply noted that 
this information, if added as proposed, is a new MIME header and didn't 
have anything to do with IMAP *except* that it is yet another new 
Content-{mumble} header that is a pain in the ass to retrieve via IMAP.
 
> > *** Body part read indication
> > - assertion that there are other ways to do this
> 
> Again, a summary?  What other ways are there to do this?

The requirement itself was called into question.   The premise for the 
requirement was that one body part was the "distinguished" body part of 
the message and reading it really indicates that the message has been 
"seen" by the user.   It was noted that advice in the message headers that
indicate which part is distringuished, thus providing advice to the client
on when to explicitly set the seen flag is (perhaps) a better approach.   
In any event, the concensus was to punt this back for further thought.

If push comes to shove, this requirement could be satisfied by ANNOTATE.

My personal opinion is that this requirement was an attempt to cure a 
symptom that most IMAP clients allow the implicit SEEN flag setting to 
occur on messages as a result of fetching any body part.   For the most 
part this is OK and saves round trips.   It doesn't do what the VPIM folks
want to do though.   I think that really this is client behaviour problem 
and that providing advice through a header (pick your RFC822/MIME header 
candidate) would be sufficient to solve the problem rather than making 
this particular extension to the protocol.

Cheers.
---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Tue, 20 Jul 1999 12:17:36 -0400
From: John Stracke <[email-masked]>
To: [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

Steve Hole wrote:

> > That is a point.  On the other hand, XML parsers can be pretty
> > small--I've
> > written one that takes up only about 50K--and they're pretty common these
> > days; many MUAs will already have one in the program somewhere.
>
> A validating parser?

No.  I agree that a validating parser is likely to be heavier than you need.  On
the other hand, it may be the case that you don't need validation for a property
model, since virtually everything interesting is going to be inside the property
elements, which the DTD can't cover anyway.  (Bias alert: I don't think validating
parsers ever make sense, since a robust app is going to have to do its own
double-checking anyway.)

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Date: Tue, 20 Jul 1999 09:20:39 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: Oslo WG meeting notes
Sender: [email-masked]

There are a few items here that are sufficiently brief that I'd like a 
bit more information.

> *** Transcoding Request
> - assertion that there are substantial interoperability issues
> - better dealt with by picking standardized represention of content-type

Can someone summarize the discussion?  In particular, how does "picking 
[a] standardized represen[ta]tion" address the issue of, say, sending a 
high-res, high-colour image on a low-bandwidth connection to a device that 
can only display 16 colours in low-res?  I'd like to get some idea of what
people were saying on this issue.

> *** Message length indication
> - assertion that this is not an IMAP issue - it is MIME issue

What *is* this issue?

> *** Body part read indication
> - assertion that there are other ways to do this

Again, a summary?  What other ways are there to do this?

Thanks.  Sorry I couldn't be there.  :-(

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Mon, 19 Jul 1999 17:46:01 -0600
To: John Stracke <[email-masked]>
Subject: Re: Annotations: alternate data model
Cc: [email-masked]
Sender: [email-masked]

On Mon, 19 Jul 1999 17:52:44 -0400 John Stracke <[email-masked]> wrote:

> That is a point.  On the other hand, XML parsers can be pretty 
> small--I've
> written one that takes up only about 50K--and they're pretty common these
> days; many MUAs will already have one in the program somewhere.

A validating parser?   As soon as you make it validating it gets both much
bigger and much slower.   This may more may not be an issue, but they are 
certainly not without cost.

> > I'm not sure we want to
> > lay this burden on IMAP servers and clients.
> 
> To me, what it comes down to is: can you come up with anything else that does
> what you need (structured data, internationalization, clean namespaces for
> properties) and costs less?

An alternate model is a subset of what ACAP does.   It has the advantage 
of an existing IMAP like syntax and semantic that both IMAP clients 
servers are familiar with.
 
> Of course, there are bits of XML that may not be worthwhile--for example, the
> requirement that any XML parser be able to grok the internal DTD gets a bit
> annoying.  But you could probably specify that XML documents used by ANNOTATE
> must not include an internal DTD (that'd probably cut your minimal parser size
> in half).

Exactly.   A well-formed parser like expat is not too big, but it still 
seems like a lot for what we want to do.

The biggest issue is that the stuff that is pushed onto the server is 
semantically owned by the client.   The server really doesn't need to know
anything about the data -- it is simply a blob.   This is true for 
everything but "magic" metadata supplied by the server, in which case a 
prearranged semantic agreement is made.   This was dealt with in ACAP 
using either standard options or ACAP dataset class specifications.   Even
that seems somewhat heavy to me.
 
Cheers.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Mon, 19 Jul 1999 16:55:23 -0600
To: IMAP Extensions Working Group <[email-masked]>
Subject: Summary of actions from Oslo WG meeting
Sender: [email-masked]

Here is a summary of the actions resulting from the Oslo meeting.
---
A - Pete Resnick - to post strawman wg milestones based to list for
    inclusion in charter.

A - Pete Resnick - to post charter to IESG for approval as working
    group. 

A - Cyrus Daboo - raise issue of multiple views on list with a summary
    of discussion at Oslo.

A - Cyrus Daboo - raise issue of dynamic views on list with a summary of
    dicussion at Oslo.

A - Cyrus Daboo - change spec to resolve VIEW SEARCH / UID SEARCH
    inconsistency.

A - Mark Crispin - publish new version of original SORT extensionas an
    historical specification.

A - Mark Crispin, Cyrus Daboo - publish a new SORT2 extension that uses
    the VIEW framework.

A - Mark Crispin - raise issue of additional threading algorithms for
    threading extensions.  Includes definition of mechanism for
    requesting desired threading mechanism.

A - Mark Crispon - publish a new extended THREAD draft for discussion on
    the list.

A - John Myers - publish a new version of the ACL extension that
    includes feedback obtained from previous IMAPext sessions.

A - Mark Crispin - raise issue of expressing access semantics that
    reflect underlying filesystem and/or store access control semantics
    on list.   Expressed as a set of requirements.

A - Cyrus Daboo, Randy Gellens - publish mailbox annotations extension
    draft for discussion on list.

A - Cyrus Daboo - raise issue on usefulness of mailbox level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

A - Cyrus Daboo - raise issue on usefulness of store level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

A - Mike Gharns - publish LANGUAGE as it is now modulo minor changes
    received via the list.

A - Mike Gharns, Mark Crispin and others to work on full internationalization
    framework for doing extension work in the future and making sure that
    all working group items are internalization friendly.   Go to the list
    to determine whether or not there are milestones for this work in the
    wg charter.

A - Randy Gellens, Stewart McRae, Glenn Parsons - publish BINARY fetch
    extension for discussion on list.

A - Mike Gharns - publish updated draft of CHILD for discussion on the
    list. 

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Mon, 19 Jul 1999 16:47:52 -0600
To: IMAP Extensions Working Group <[email-masked]>
Subject: Oslo WG meeting notes
Sender: [email-masked]

Notes for the IMAP Extensions Working Group at the 45th IETF meeting in
Oslo Norway, July 15, 1999.

WG Chair - Pete Resnick <[email-masked]>
Mailing List - <[email-masked]>

Notes - Steve Hole <[email-masked]>

Viewing the notes looks best in outline-mode of Emacs (if you care).

Action items identified during the working group are tagged with a
leading "A", followed by the action item owner (victim) and a
description of the deliverable.

A separate summary of action items will be posted to the list as a
separate document.

* Agenda bashing:
** Charter bashing
** View/sort/thread
** ACL
** Annotations
** ID
** Language
** VPIM
** Other Issues

*** list rathole
- we seek to avoid all discussion on extensions to the LIST command because
  it is a gigantic rathole.   This will be discussed in future events.

* WG Charter Bashing

** reviewed charter with exception of milestones
** charter accepted for use as a working group
** We will resolve milestones at end of meeting (if time) but otherwise on list.

A - Pete Resnick - to post strawman wg milestones based to list for
    inclusion in charter.
A - Pete Resnick - to post charter to IESG for approval as working
    group. 

* View extension - Cyrus Daboo
** Review of existing draft and proposal

- goal is to provide a subsetting facility for IMAP
- new commands "VIEW SET" and "VIEW"
- result is to set a new context that results in a set of "view specifiers"
  that allows the client to access messages based on the specifiers (rather
  than sequence number and/or uid.
- new data item for FETCH command named "VIEW"
- new VIEW untagged response 

** Is it worthwhile to proceed?
- good concensus to proceed

** Overloaded SELECT
- Mark C proposes an additional extension that is VIEW extended version
  of SELECT/EXAMINE
- concensus to add this to the proposal
- John M notes that this prevents getting EXISTS prior to issuing a VIEW

** Support for multiple VIEWS
- very expensive for the server implementors
- will clients actually use it?
  - there are examples of how a client might use it.
  - some vendors clearly expressed a desire to have it.
- there are other workarounds (multiple connections, refining criteria
  on reissued VIEW)
- punt issue to list

A - Cyrus Daboo - raise issue of multiple views on list with a summary
    of discussion at Oslo.

** Dynamic views - yes or no?
- concensus that we want dynamic insertion into the view.
- do we want dynamic removal from the view?
  - difficult because proper UI behaviours are debatable
  - discussion on whether behaviour could be asked for
  - discussion on relative difficulty of supporting this in server
  - assertion that client MUST be able to specify the static vs. dynamic
    notification behaviour
  - breakout of technical issues on what information a client has to have
    to be able to deal with removal

A - Cyrus Daboo - raise issue of dynamic views on list with a summary of
    dicussion at Oslo.

** Issues with VIEW SEARCH
- assertion that VIEW SEARCH is inconsisten UID SEARCH
- there is an easy fix to the spec to deal with this that Cyrus will make

A - Cyrus Daboo - change spec to resolve VIEW SEARCH / UID SEARCH
    inconsistency. 

** VIEW with SORT
- original proposal by Mark Crispin to publish as
  historic/informational/experimental 
- extensions to original SORT with additional sort keys and better
  defined subject sort methodology.

A - Mark Crispin - publish new version of original SORT extensionas an
    historical specification.
A - Mark Crispin, Cyrus Daboo - publish a new SORT2 extension that uses
    the VIEW framework.

** VIEW with THREADING
- create a THREAD extension based on VIEW
- Mark C reviews his existing THREAD implementation

A - Mark Crispin - raise issue of additional threading algorithms for
    threading extensions.  Includes definition of mechanism for
    requesting desired threading mechanism.

A - Mark Crispon - publish a new extended THREAD draft for discussion on
    the list.

* ACLs - John Myers
** Issues with existing proposed standard described in RFC2086
- impose more restrictions on server semantics
- identifier namespace for groups
- difficulty in expressing underlying access semantics via ACL (ie. UNIX
  access modes via ACLs)

A - John Myers - publish a new version of the ACL extension that
    includes feedback obtained from previous IMAPext sessions.

** Discussion on "expressability" of ACLs
- issues with how clients can handle expression of tied rights etc.
- a lot of discussion on how it might be possible to support
  requirements.
- assertion that "mapping" of rights was a rathole in other protocol
  work.

A - Mark Crispin - raise issue of expressing access semantics that
    reflect underlying filesystem and/or store access control semantics
    on list.   Expressed as a set of requirements.

* Annotate extension - Cyrus Daboo

** Strawman model
- allow clients and servers to add metadata to messages
- add FETCH ANNOTATION item
- add STORE +ANNOTATION
- add support for search and sort on annotation

** Issues
*** Is this of interest?
- good concensus that this is useful

*** Is this mechanism acceptible?
- good concensus that it is a good strawman model for a draft that
  addresses mailbox annotations

*** Extend to include mailbox and server annotations?
- mailbox sounds interesting
- server may be interesting
- resolution to be taken to list

*** Are ACLs on annotations too complex for now?
- yes

A - Cyrus Daboo, Randy Gellens - publish mailbox annotations extension
    draft for discussion on list.

A - Cyrus Daboo - raise issue on usefulness of mailbox level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

A - Cyrus Daboo - raise issue on usefulness of store level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

* Client ID - Tim Showalter (in absensia)

** Issues
*** Do we want to do it?
- *very* useful for tracking
- assertion that some people will implement it no matter what
- it is open to abuse (restrictions by server for a particular client set)

*** Should it be in the scope of the working group?
- it will not be discussed within the working group
- discussion to the IMAP - not IMAPEXT working group

* LANGUAGE - Mike Garhns

** Issues
*** There are implementations of existing draft
- the number of implementations is not large (apparently)

*** Is LANGUAGE general enough?
- it addresses one part of localization
- doesn't address internationalization and other localization issues

** Solution
- discussion about a full framework that has more of the complete work
  that would subsume the functionality of LANGUAGE later on.

A - Mike Gharns - publish LANGUAGE as it is now modulo minor changes
    received via the list.

A - Mike G., Mark C and others to work on full internationalization
    framework for doing extension work in the future and making sure that
    all working group items are internalization friendly.   Go to the list
    to determine whether or not there are milestones for this work in the
    wg charter.

* VPIM Extensions - Glen Parsons

** Review of existing draft
- draft-ema-vpim-imap-01.txt 

** Where should it be discussed (which working group)?
- concensus that the parts that are general IMAP functionality should be
  discussed in IMAP extensions.
- VPIM specific stuff goes into VPIM.

** Issues
- assertion that there is danger about doing specific extensions to
  support a particular application ie. VPIM
- resolved to try to make sure that we take a stance of general
  applicability to IMAP.

*** Binary Attachment Transfer
- pull a binary object from the store (remove encodings)
- good concensus that this is both generally applicable and should be
  addressed by this group

A - Randy Gellens, Stewart McRae, Glenn Parsons - publish BINARY fetch
    extension for discussion on list.

*** External Reference
- may be applicable to other applications
- security issues raised

*** Transcoding Request
- assertion that there are substantial interoperability issues
- better dealt with by picking standardized represention of content-type

*** Streaming Audio Attachments
- assertion that PARTIAL support is sufficient for this
- we will not deal with this

*** Message length indication
- assertion that this is not an IMAP issue - it is MIME issue
- we will not deal with this

*** Body part read indication
- assertion that there are other ways to do this
- we will not deal with this

* Other Extensions
** Child mailbox draft
*** Issues
- should we continue with this?
- recommendation to come up with a general mechanism for handling LIST
  extensions in general.

A - Mike Gharns - publish updated draft of CHILD for discussion on the
    list. 

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Mon, 19 Jul 1999 17:52:44 -0400
From: John Stracke <[email-masked]>
To: [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

Cyrus Daboo wrote:

> > (Of course, this may not make as much sense in IMAP as in WebDAV, where
> > most of the protocol information is carried in XML in the first place.)
>
> This is the issue. WebDAV has everything wrapped up in an XML document. It
> requires XML parsers on both the server and client.

That is a point.  On the other hand, XML parsers can be pretty small--I've
written one that takes up only about 50K--and they're pretty common these
days; many MUAs will already have one in the program somewhere.

> I'm not sure we want to
> lay this burden on IMAP servers and clients.

To me, what it comes down to is: can you come up with anything else that does
what you need (structured data, internationalization, clean namespaces for
properties) and costs less?

Of course, there are bits of XML that may not be worthwhile--for example, the
requirement that any XML parser be able to grok the internal DTD gets a bit
annoying.  But you could probably specify that XML documents used by ANNOTATE
must not include an internal DTD (that'd probably cut your minimal parser size
in half).

Up to you.  I don't know enough about how IMAP is used to be able to figure
the tradeoffs; I just know XML.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Date: Mon, 19 Jul 1999 17:33:45 -0400
From: Cyrus Daboo <[email-masked]>
To: John Stracke <[email-masked]>, [email-masked]
Subject: Re: Annotations: alternate data model
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

Hi John,

--On Thu, Jul 15, 1999 2:27 PM +0200 John Stracke <[email-masked]> wrote:

> The strawman annotation model that was presented suggested a basic
> name/value data model, but also mentioned the possibility of wanting to
> permit values to be large binary blobs.  Rather than develop a new
> syntax for doing this, you might want to adopt something like the WebDAV
> property model, in which a property is an XML element.  The name of the
> element becomes the name of the property, and you get to use all the
> features of XML (structured data, internationalization, namespaces,
> etc.).

I had another look at the WebDAV RFC after your comments and there are some
interesting things there that could be applied to ANNOTATE. But...

> (Of course, this may not make as much sense in IMAP as in WebDAV, where
> most of the protocol information is carried in XML in the first place.)

This is the issue. WebDAV has everything wrapped up in an XML document. It
requires XML parsers on both the server and client. I'm not sure we want to
lay this burden on IMAP servers and clients.

Though not being a WebDAV/XML expert I'm certainly open to suggestions as
to how this might be applied to ANNOTATE.

--
Cyrus

Date: Thu, 15 Jul 1999 14:27:27 +0200
From: John Stracke <[email-masked]>
To: [email-masked]
Subject: Annotations: alternate data model
Sender: [email-masked]

(I'm sitting in the BOF right now, but this idea is both relatively
unimportant and potentially inflammatory, so I'm not going to waste
face-to-face time.  :-)

The strawman annotation model that was presented suggested a basic
name/value data model, but also mentioned the possibility of wanting to
permit values to be large binary blobs.  Rather than develop a new
syntax for doing this, you might want to adopt something like the WebDAV
property model, in which a property is an XML element.  The name of the
element becomes the name of the property, and you get to use all the
features of XML (structured data, internationalization, namespaces,
etc.).

(Of course, this may not make as much sense in IMAP as in WebDAV, where
most of the protocol information is carried in XML in the first place.)

I'm not on this list, so, if you want to flame me, you'll have to
CC: me.  I probably won't flame back, though, 'cause I'm not certain
that I'm right; I just wanted to offer some cross-pollination.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Date: Thu, 08 Jul 1999 02:05:59 +0400
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>, [email-masked]
CC: Yuri Demchenko <[email-masked]>
Subject: Re: Agenda due today
Sender: [email-masked]

Alexey Melnikov wrote:

> Mark Crispin wrote:
>
> > On Fri, 2 Jul 1999, Alexey Melnikov wrote:
> > > Probably we should discuss LANGUAGE extension.
> >
> > I propose that we form a small e-mail working sub-group of people
> > interested this issue, rather than spend the limited time in Oslo.  The
> > Oslo meeting should just mention the existance of the sub-group and the
> > mailing list for it.
> >
> > This is too complex and too important of an issue to be tossed into the
> > agenda and made to compete with the other issues already in the agenda.
> >
> > I will oppose any "quick and dirty" proposal for LANGUAGE.  We have to do
> > this right, and doing it right requires careful consideration from all of
> > us.
> >
> > We need to consider localization, internationalization, and
> > mulilingualization; and from these draw up a list of desired
> > functionalties.  Among other things, we need to establish a transition
> > mechanism from ASCII and charsets to pure UTF-8.
> >
> > I have no problem with a separate face-to-face meeting of people
> > interested in LANGUAGE at Oslo.
>
> I don't mind.
>
> Let me know about date and time for LANGUAGE meeting. (BTW, I've recently
> submitted SMTP LANG draft, we may discuss it as well). I will be in Oslo all
> week.

Mike will be in Oslo as well, so he will probably agree with me that we have to
discuss LANGUAGE and all related problems.

Alexey

P.S. I will be offline from Friday up to Sunday, could we arrange this meeting
now?

Date: Mon, 28 Jun 1999 11:14:00 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Mike Macgirvin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

My only comment about multiple simultaneous views is that this makes VIEW much
more complicated to implement; and as such presents a barrier to prospective
implementors.  It may also contribute to the ongoing myth that IMAP is an
expensive service to have on a machine.

Nevertheless, this is just an observation and I don't oppose your proposal.
Please bring it up at Oslo.

Date: Mon, 28 Jun 1999 14:38:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Macgirvin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Hi Mike,

--On Monday, June 28, 1999, 10:56 AM -0700 Mike Macgirvin
<[email-masked]> wrote:

> This appears to have the side effect of limiting you to one view. Multiple
> active views would require extensive client polling, and the notification
> events would only be active on one of them. 
> 
> I'd like to propose a modest enhancement, where the client can provide a
> (client generated) view-id, and subsequent changes to that view are tagged
> with the view-id. This permits multiple active views. Granted, there is
> server overhead involved, but this is the price of moving it off the
> client in the first place. Having the client generate an ID is better
> than having to match an untagged response with a search string. 

Multiple views would be nice. I thought of doing something similar too.
However, I concluded that the added complexity of handling multiple views
is too much for now. It requires a lot more than just modifying EXISTS.

One major problem is that messages can be in more than one view. One way to
handle this would be to redefine the 'position' syntax to be a list of
'view number'/'view position' pairs. For example, an EXPUNGE for a message
in view #0001 and view #0003 would end up as:

a EXPUNGE
* 1 EXPUNGE 1234 ((0001 1)(0003 4))
a OK

My personal feeling is to keep VIEW simple for now and see how
implementation experience goes. There's no reason why later we can't define
a new command to deal with multiple named views and redefine the existing
VIEW syntax appropriately. e.g. 'VIEW SET' would be augmented by a 'VIEW
NAMEDSET' command that could redfine the 'position' formal syntax item to
be an S-Expression list (or whatever), and require a view name in addition
to the sub-command in a VIEW command.

--Cyrus

Date: Mon, 28 Jun 1999 13:16:45 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Hi folks,
A new internet draft is available at:

<http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>

This is the first cut at moving towards a standardised sorting mechanism
for IMAP. The extension proposed in this draft is actually a more general
extension that is used to allow a client to operate on a sub-set of
messages (as determined right now by an IMAP SEARCH command) as opposed to
the entire set of messages in the mailbox.

Basically this extension introduces a couple of new commands, together with
some new responses, including a new FETCH item called 'VIEW' which is the
message's position in the 'sub-set' or 'view'. Clients can then access
messages by their view position using a new VIEW command that takes FETCH
(and other commands) as arguments (inthe same way as the UID command
already present in IMAP4).

It is proposed that a future SORT extension will be used with the VIEW
mechanism to allow sub-setting of sort results and to allow clients to
access the messages in sorted order as opposed to sequence number order.
Thus this draft represents the first step towards the goal of a sort
command acceptable to all - hopefully!

BTW that the VIEW mechanism can be used with other types of sub-setting we
might want to think about in the future (e.g. message threading based on
message-id/in-reply-to etc).

Note that this document proposes a mechanism different from that discussed
by various groups at recent IETF and IMC interop meetings. I can post a
list of reasons why we feel this approach is better if there is interest.

--Cyrus Daboo

Date: Mon, 28 Jun 1999 10:56:26 -0700
From: Mike Macgirvin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

This appears to have the side effect of limiting you to one view. Multiple
active views would require extensive client polling, and the notification
events would only be active on one of them. 

I'd like to propose a modest enhancement, where the client can provide a
(client generated) view-id, and subsequent changes to that view are tagged
with the view-id. This permits multiple active views. Granted, there is
server overhead involved, but this is the price of moving it off the client
in the first place. Having the client generate an ID is better than having
to match an untagged response with a search string. 

        C: A143 VIEW SET 0001 SEARCH FROM "Smith"
        S: * 172 EXISTS 0001 23
        S: A143 OK VIEW SET completed
	C: A144 VIEW SET 0002 SEARCH FROM "Myboss"
	S: * 172 EXISTS 0001 23 0002 6
	S: A144 OK VIEW SET completed

It probably isn't necessary that the results be chained in the EXISTS
response, i.e. 

	S: 172 EXISTS 0001 23
	S: 172 EXISTS 0002 6

would be just fine. 

This would alter other responses appropriately. This way mailbox events can
trigger updates of any active views.
Thinking one step further, something to shut down an active view would
likely be desirable in this model. 

	C: A145 VIEW REMOVE 0001
	S: A145 OK VIEW 0001 FROM "Smith" removed

If I'm missing something obvious and all this isn't necessary, please
correct me.

Date: Mon, 28 Jun 1999 11:02:57 -0700
From: Mike Macgirvin <[email-masked]>
To: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Before somebody corrects me - yes I do know that EXISTS are untagged and
require *.

> It probably isn't necessary that the results be chained in the EXISTS
> response, i.e. 

>        S: * 172 EXISTS 0001 23
>        S: * 172 EXISTS 0002 6
............^

> would be just fine.

Date: Mon, 28 Jun 1999 12:45:31 -0700
From: Mike Macgirvin <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Mark Crispin wrote:
> 
> My only comment about multiple simultaneous views is that this makes VIEW much
> more complicated to implement; and as such presents a barrier to prospective
> implementors.  It may also contribute to the ongoing myth that IMAP is an
> expensive service to have on a machine.
> 
> Nevertheless, this is just an observation and I don't oppose your proposal.
> Please bring it up at Oslo.

I agree totally that it makes server implementation of this feature
non-trivial. Without it I think the client ends up having to work just as
hard by issuing multiple SEARCH and/or VIEW commands everytime anything in
the mailbox changes - or doing all the work client-side. We can do that
today without requiring any extensions, but it's hardly efficient. So this
draft presents a way to avoid a lot of client overhead as long as you only
define or "activate" only one view. Having worked a lot with views in the
past, one is not very typical. The bell curve fits around 5 and 20 at least
on INBOX and it's reasonable for a human to want to have all their views
active in the sense that message counts are propogated in as near to real
time as possible. 

I'll see if somebody else from here will be at Oslo and ask that they
present these arguments - unfortunately, I have other obligations.

Date: Mon, 28 Jun 1999 17:52:36 -0400
Reply-To: [email-masked]
From: Tony Hansen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> A new internet draft is available at:
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
> 
> This is the first cut at moving towards a standardised sorting mechanism
> for IMAP. The extension proposed in this draft is actually a more general
> extension that is used to allow a client to operate on a sub-set of
> messages (as determined right now by an IMAP SEARCH command) as opposed to
> the entire set of messages in the mailbox.
> 
> Basically this extension introduces a couple of new commands, together with
> some new responses, including a new FETCH item called 'VIEW' which is the
> message's position in the 'sub-set' or 'view'. Clients can then access
> messages by their view position using a new VIEW command that takes FETCH
> (and other commands) as arguments (inthe same way as the UID command
> already present in IMAP4).
> ...

Our major problem with this proposal is not an issue with the extension
itself. Instead, we have an issue with its impact on server performance
when dealing with LARGE user populations (hundreds of thousands or
millions). Each proposal such as this does increase the server load.

	Tony Hansen
	[email-masked]

Date: Mon, 28 Jun 1999 15:05:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: [email-masked]
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

On Mon, 28 Jun 1999 17:52:36 -0400, Tony Hansen wrote:
> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

There's a tradeoff in all of these things.  Some people consider the
functionality of VIEW to be very important, and have blocked SORT and THREAD
unless this functionality is provided.  One of their concerns is that the SORT
command uses communication bandwidth; for example, sorting a 2000 message
mailbox results in a response that is 8900 octets long.

SORT and THREAD are very important for UW since these extensions make a *HUGE*
difference in Pine performance.  So, it's important for us to get these
concerns addressed, and preferably in an extensible mechanism.

Date: Mon, 28 Jun 1999 20:28:06 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

--On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:

> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

Actually the hope for this proposal (wrt to sorting) is to REDUCE the
overall server load by removing the need for a client to download the
envelopes of all messages in order to sort them for the end-user. It should
also reduce client load and indeed allow thin-clients to present sorted or
sub-set views without having to do much work.

--
Cyrus

Date: Tue, 29 Jun 1999 00:38:15 +0000
From: steve spear <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Can someone explain how traffic is reduced by SORT over clients that are
caching the headers and simply request messages headers they haven't seen
before?   As Tony Hansen pointed out - AT&T is trying to handle many millions
of users.  The thought of using more resources on the server instead of the
clients that are largely idle is a concern of ours.  We keep hearing about
thin-client's, but the memory available in the thin clients still boggles the
mind of those who had memory measured in Kilobytes ( not Megabytes ) 25+ years
ago.  If it makes sense we'll cheer for it,  but we'd like to understand where
the advantage is.

Steve Spear
AT&T Technology Consultant

Cyrus Daboo wrote:

> --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:
>
> > Our major problem with this proposal is not an issue with the extension
> > itself. Instead, we have an issue with its impact on server performance
> > when dealing with LARGE user populations (hundreds of thousands or
> > millions). Each proposal such as this does increase the server load.
>
> Actually the hope for this proposal (wrt to sorting) is to REDUCE the
> overall server load by removing the need for a client to download the
> envelopes of all messages in order to sort them for the end-user. It should
> also reduce client load and indeed allow thin-clients to present sorted or
> sub-set views without having to do much work.
>
> --
> Cyrus

Date: Mon, 28 Jun 1999 18:40:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: steve spear <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

On Tue, 29 Jun 1999 00:38:15 +0000, steve spear wrote:
> Can someone explain how traffic is reduced by SORT over clients that are
> caching the headers and simply request messages headers they haven't seen
> before?

Most such clients are POP clients masquerading as IMAP clients.  Consider true
IMAP clients, which don't have a cache (and may well be a kiosk or other
shared machine which shouldn't cache!), and don't want to load all those
headers.

Date: Tue, 29 Jun 1999 15:21:52 -0400
From: Barry Leiba <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

First comment:  Can we take the IMAP mailing list out of the list on
this discussion, and just hold it on the IMAPext mailing list?  It seems
silly to post the same discussion to both lists -- why do we have the
IMAPext list at all, if we're going to do that?

Other comments:
* Section 4.1 refers to an "optional" sub-command, and (a) says that 
  the  VIEW SET command selects messages that "match the results of the
  sub-command".  It doesn't make it clear what happens if there's no
  sub-command (all messages are selected, I presume).  It also doesn't
  say much about the sub-command; if "SEARCH" is the only command in
  the base spec that applies, it should probably say so, to prevent
  people from wondering what commands apply.  It might also say (which
  is also said elsewhere) that it's intended that future SORT and 
  THREAD commands may go here.

* In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the
  wrong Latin abbreviation here.  "cf." means "compare" (from the Latin
  "confer"), and I don't think you want anyone to compare what you say
  here to what's said in 4.2.  If you mean "see section 4.2", just say it.
  (Sorry... pet peeve about misuse of Latin abbreviations.)

* In the example in 4.1 (g), correct spelling of "SEARCH".

* In 4.2 you should make it clear what, if anything, it means to use a
  VIEW command without a VIEW SET being in effect.  It seems to me that
  it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
  case?).

* In 4.2, you say
    command response.  However, server implementations MUST implicitly
    include the VIEW fetch item as part of any FETCH response caused by
    a VIEW command, regardless of whether a VIEW was specified as a
    message data item to the FETCH.

  ...but you've already said that a VIEW fetch item must be included if
  a VIEW SET is in effect.  If I'm right in my previous note, then you
  probably shouldn't *also* say this.

* In 5.1.1:
    A VIEW untagged response MUST NOT be sent when no command is in
    progress; nor while responding to a FETCH, SEARCH or STORE command.

  Understandable.  But that means that a client that receives an EXISTS
  in response to a FETCH must then go issue a NOOP to get the corresponding 
  VIEW response.  Can we think of a better way?

  Also, it might not hurt to point out that IDLE can count as a command
  in progress.  But, then, maybe that's too obvious to have to mention.

* In 5.1.2:
    When the old view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message inserted into the view at
    the position given by <new>.  The view position numbers of all
    subsequent messages inthge current view are incremented.

    When the new view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message removed from the view at
    the position given by <old>.  The view position numbers of all
    subsequent messages inthe current view are decremented.

  In both of these, I think you mean "zero" where you say "non-zero".
  Also, fix "inthge" and "inthe".
  Also also, since you explicitly talk about incrementing and decrementing
  view position numbers, perhaps you should include a paragraph about what
  happens if both the old and new positions are non-zero... which also
  require renumbering other messages.  No, *I* don't think it needs to be
  said, but, then, I'm always surprised at the interpretations that sometimes
  happen when one fails to say something.  :-)

* In the grammar:
    position         ::= number ["." number]
                         ;; position number of messages in the view
                         ;; may be hierarchical if sub-command defines
                         ;; hierarchic ordering of messages

  This makes some of the statements about "incrementing" and "decrementing"
  view positions harder to understand.  Maybe all we should say about what
  happens after a VIEW response is that "view positions of subsequent [or
  intervening] messages must be adjusted appropriately" or some such.

* Finally, just to clarify things... we'd had an extended discussion about
  whether it was reasonable to remove a message from a view, once it was
  in the view.  Problems of side-effects and such -- for instance, what 
  happens in the following case (abbreviating a little):
    c: t0 VIEW SET SEARCH UNSEEN
    s: * 25 VIEW 1234 0 4
    c: t1 VIEW FETCH 4 BODY[1]
    s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ...
    s: t1 OK done
    c: t2 NOOP
    s: * 25 VIEW 1234 4 0    [\Seen flag caused view to change]
    s: t2 OK done

  Now, as a side-effect of the FETCH, the client can no longer use VIEW FETCH
  on this message.  Other cases are easy to imagine.  It makes VIEW FETCH of
  questionable use.

  Clearly, the decision made in writing this draft was to have messages 
  disappear from the view (during earlier discussions, some thought they 
  should not, though it came out that that makes reconnecting after connection 
  failures difficult).

  I just wanted to point out, for the record, that there were two sides to
  that discussion, and to point out, for the record, which one was adopted.
  (And, for the record, I agree with the choice.)

  But I would like to see some of these potential problems mentioned in the 
  spec.  I would also like to see some encouragement to use UIDs instead of
  view positions.  In fact, I'd go as far as to say that I don't think we
  should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
  should clearly state that UIDs are the things to use when you're using views.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 29 Jun 1999 16:25:56 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

First, an apology.  My contribution to this document so far has been mostly
architectural, so if I say something that doesn't fully mesh with what the
document says, keep this in mind.

> * Section 4.1 refers to an "optional" sub-command, and (a) says that
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

I thought that VIEW SET without a command was to cancel the view.  If this
isn't specified, it should be.

>   It also doesn't
>   say much about the sub-command; if "SEARCH" is the only command in
>   the base spec that applies, it should probably say so, to prevent
>   people from wondering what commands apply.  It might also say (which
>   is also said elsewhere) that it's intended that future SORT and
>   THREAD commands may go here.

Let's talk about the wordsmithing for this at Oslo.  VIEW SET's command
argument is a command that defines a set (and, potentially, ordering) of
messages.  I agree that this needs to be well-specified, but I don't want to
tag/limit it to SEARCH/SORT/THREAD even if that's the actual situation today.

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

I think that it's a BAD.

>   I would also like to see some encouragement to use UIDs instead of
>   view positions.  In fact, I'd go as far as to say that I don't think we
>   should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
>   should clearly state that UIDs are the things to use when you're using
>   views.

You need some way to express hierarchy in a VIEW (for threading), which is why
neither sequence numbers nor UIDs are good enough.  If you use either a
sequence number or UID (I don't think that one should be preferred over the
other, beyond what technical considerations indicate), then you have to
maintain the map or some portion of it.

The whole point for VIEW FETCH and friends is so you don't need to have the
map at all.

Date: Fri, 02 Jul 1999 03:08:51 +0400
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: Agenda due today
Sender: [email-masked]

Mark Crispin wrote:

> On Fri, 2 Jul 1999, Alexey Melnikov wrote:
> > Probably we should discuss LANGUAGE extension.
>
> I propose that we form a small e-mail working sub-group of people
> interested this issue, rather than spend the limited time in Oslo.  The
> Oslo meeting should just mention the existance of the sub-group and the
> mailing list for it.
>
> This is too complex and too important of an issue to be tossed into the
> agenda and made to compete with the other issues already in the agenda.
>
> I will oppose any "quick and dirty" proposal for LANGUAGE.  We have to do
> this right, and doing it right requires careful consideration from all of
> us.
>
> We need to consider localization, internationalization, and
> mulilingualization; and from these draw up a list of desired
> functionalties.  Among other things, we need to establish a transition
> mechanism from ASCII and charsets to pure UTF-8.
>
> I have no problem with a separate face-to-face meeting of people
> interested in LANGUAGE at Oslo.

I don't mind.

Let me know about date and time for LANGUAGE meeting. (BTW, I've recently
submitted SMTP LANG draft, we may discuss it as well). I will be in Oslo all
week.

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+

From: "Mike Gahrns" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Barry Leiba" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Date: Thu, 1 Jul 1999 14:05:05 -0700
Sender: [email-masked]

> > * In 5.1.2:
> >     When the old view position number in the VIEW untagged response is
> >     non-zero, the effect of VIEW is a message inserted into the view at
> >     the position given by <new>.  The view position numbers of all
> >     subsequent messages inthge current view are incremented.
> >
> >     When the new view position number in the VIEW untagged response is
> >     non-zero, the effect of VIEW is a message removed from the view at
> >     the position given by <old>.  The view position numbers of all
> >     subsequent messages inthe current view are decremented.
> >
> >   In both of these, I think you mean "zero" where you say "non-zero".
>
> Yup, that's wrong in the document.
*** I also think that you have the order of <new> and <old> view numbers
reversed in your examples in this section relative to the definition of view
response you give in 5.1.2

Date: Thu, 1 Jul 1999 15:22:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda due today
Sender: [email-masked]

On Fri, 2 Jul 1999, Alexey Melnikov wrote:
> Probably we should discuss LANGUAGE extension.

I propose that we form a small e-mail working sub-group of people
interested this issue, rather than spend the limited time in Oslo.  The
Oslo meeting should just mention the existance of the sub-group and the
mailing list for it.

This is too complex and too important of an issue to be tossed into the
agenda and made to compete with the other issues already in the agenda.

I will oppose any "quick and dirty" proposal for LANGUAGE.  We have to do
this right, and doing it right requires careful consideration from all of
us.

We need to consider localization, internationalization, and
mulilingualization; and from these draw up a list of desired
functionalties.  Among other things, we need to establish a transition
mechanism from ASCII and charsets to pure UTF-8.

I have no problem with a separate face-to-face meeting of people
interested in LANGUAGE at Oslo.

Date: Fri, 02 Jul 1999 01:59:51 +0400
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda due today
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Thursday, July 01, 1999, 3:21 PM -0500 Pete Resnick
> <[email-masked]> wrote:
>
> > In among my mayhem, I'd forgotten that I was supposed to get an
> > agenda for the BOF in today. I'll get it in late today and hope I
> > don't get yelled at. I assume we'll spend a little time on the
> > charter, but then what's on the plate?
> >
> > I'm sending something in by 6PM CDT today (so that Marcia doesn't
> > beat me up) with or without input, so please send input ASAP.
> > Otherwise, I'll make something up.
>
> I guess we want something like:
>
> 1) Charter completion - approval of WG status
> 2) Discuss VIEW/SORT drafts (long)
> 3) Discuss ACL2 (should consult John Myers to see how much he's been able
> to do on this)
> 4) Discuss annotations (short as there's no real draft yet, but a general
> 'how should we do it' discussion would be good)
> 5) Discuss other extensions not on the 'official' charter (e.g. Client ID
> and anything else that folks want to bring up)

Probably we should discuss LANGUAGE extension.

--
Best Regards,
Alexey Melnikov

Date: Thu, 01 Jul 1999 16:29:51 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda due today
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Thursday, July 01, 1999, 3:21 PM -0500 Pete Resnick
<[email-masked]> wrote:

> In among my mayhem, I'd forgotten that I was supposed to get an 
> agenda for the BOF in today. I'll get it in late today and hope I 
> don't get yelled at. I assume we'll spend a little time on the 
> charter, but then what's on the plate?
> 
> I'm sending something in by 6PM CDT today (so that Marcia doesn't 
> beat me up) with or without input, so please send input ASAP. 
> Otherwise, I'll make something up.

I guess we want something like:

1) Charter completion - approval of WG status
2) Discuss VIEW/SORT drafts (long)
3) Discuss ACL2 (should consult John Myers to see how much he's been able
to do on this)
4) Discuss annotations (short as there's no real draft yet, but a general
'how should we do it' discussion would be good)
5) Discuss other extensions not on the 'official' charter (e.g. Client ID
and anything else that folks want to bring up)

--
Cyrus

Date: Thu, 1 Jul 1999 15:21:27 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Agenda due today
Sender: [email-masked]

In among my mayhem, I'd forgotten that I was supposed to get an 
agenda for the BOF in today. I'll get it in late today and hope I 
don't get yelled at. I assume we'll spend a little time on the 
charter, but then what's on the plate?

I'm sending something in by 6PM CDT today (so that Marcia doesn't 
beat me up) with or without input, so please send input ASAP. 
Otherwise, I'll make something up.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

From: "Mike Gahrns" <[email-masked]>
To: "Rubinstein, Dmitry" <[email-masked]>, <[email-masked]>
Subject: Re: Client ID extension
Date: Thu, 1 Jul 1999 09:45:03 -0700
Sender: [email-masked]

Dmitry writes:
> > From: Mike Gahrns [mailto:[email-masked]]
> > Given that there seems to be
> > reasonable
> > number of people who concur that this type of functionality
> > would be useful,
> > moving the extension forward should hopefully be rather
> > straight foward with
> > only minor changes needed.
>
>
> OK then, what are the needed changes? Below is the original draft for your
> reference.
Since there was a lot of concerns about the potential abuse of it and
privacy concerns, we probably should have stronger language regarding the
caveats around this to avoid potential abuse.  e.g. in the client parameter
list it states any value over and above the defined fields can be sent.  I
think you'd want a stronger privacy statement here, in case people start
sending more than the defined fields and include things like Processor ID,
MAC address etc.  (I certainly don't want to start a discussion regarding
the merits or non-merits of including this type of info, but I think it
would be wise to have strong language here)

In the security section,  it should be noted that knowing the make/type of
client/server could make it easier for hackers to exploit known
vulnerabilities with particular software.

If you cruise through the IMAP archives you'll probably find some other
comments as well.  If memory serves me correctly, I think the author, Tim
Showalter, said that he had a list of changes he wanted to incorporate.

In any event, I think any changes would be minor in nature, and would be
more along the lines of "editorial" type changes.

Date: Wed, 28 Jul 1999 21:05:42 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: John Haxby <[email-masked]>
CC: [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

John Haxby wrote:
> 
> > Non-validating XML parsers are fairly cheap to implement and are freely
> > available.
> 
> Could you provide some pointers to these freely available parsers?

Some free parsers are available at:

	http://www.w3.org/Library/		non-validating (C)
	http://www.alphaworks.ibm.com/		validating (C++,Java)

	Tony Hansen
	[email-masked]

Date: Wed, 28 Jul 1999 16:30:25 +0100
From: John Haxby <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------914A13F32093D2B4108DB02C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[email-masked] wrote:

> Non-validating XML parsers are fairly cheap to implement and are freely
> available.

Could you provide some pointers to these freely available parsers?

>
> I've been using XML in some projects here and like a lot of its
> features. We did have to do something about representing binary values
> within XML, but otherwise are fairly pleased with XML as a data
> representation language.

I have to agree here.

It's certainly a lot easier to get to grips with than ASN.1!

jch

--------------914A13F32093D2B4108DB02C
Content-Type: text/x-vcard; charset=us-ascii;
 name="jch.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John Haxby
Content-Disposition: attachment;
 filename="jch.vcf"

begin:vcard 
n:Haxby;John
tel;work:+44 1344 763711
x-mozilla-html:FALSE
url:http://www.hp.com/go/OpenMail
org:Hewlett Packard;OpenMail R&D<img src="http://www.ice.hp.com/cyc/om/50/graphics/omlinux.jpg" width=53 height=62 align=top>
adr:;;Nine Mile Ride;Wokingham;Berks;RG40 3LL;England
version:2.1
email;internet:[email-masked]
x-mozilla-cpt:;14976
fn:John Haxby
end:vcard

--------------914A13F32093D2B4108DB02C--

Date: Wed, 28 Jul 1999 09:57:03 -0400
From: Tony Hansen <[email-masked]>
Organization: AT&T Laboratories
To: [email-masked]
CC: John Stracke <[email-masked]>
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> > The strawman annotation model that was presented suggested a basic
> > name/value data model, but also mentioned the possibility of wanting to
> > permit values to be large binary blobs.  Rather than develop a new
> > syntax for doing this, you might want to adopt something like the WebDAV
> > property model, in which a property is an XML element.  The name of the
> > element becomes the name of the property, and you get to use all the
> > features of XML (structured data, internationalization, namespaces,
> > etc.).
> 
> I had another look at the WebDAV RFC after your comments and there are some
> interesting things there that could be applied to ANNOTATE. But...
> 
> > (Of course, this may not make as much sense in IMAP as in WebDAV, where
> > most of the protocol information is carried in XML in the first place.)
> 
> This is the issue. WebDAV has everything wrapped up in an XML document. It
> requires XML parsers on both the server and client. I'm not sure we want to
> lay this burden on IMAP servers and clients.
> 
> Though not being a WebDAV/XML expert I'm certainly open to suggestions as
> to how this might be applied to ANNOTATE.

Non-validating XML parsers are fairly cheap to implement and are freely
available. You're going to have to have a parser anyway, and an XML
parser isn't overly harder than a parser for any other data
representation language.

I've been using XML in some projects here and like a lot of its
features. We did have to do something about representing binary values
within XML, but otherwise are fairly pleased with XML as a data
representation language.

	Tony Hansen
	[email-masked]

Date: Fri, 23 Jul 1999 15:49:14 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>, Barry Leiba <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Subject: Re: per-part message flags (was: Oslo WG meeting notes)
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Fri, Jul 23, 1999 1:11 PM -0600 Steve Hole
<[email-masked]> wrote:

> In fact, with some clever thinking we might be able to allow scoping 
> management to be explicit, and have the standard per-message flags
> exposed  as part of the annotation data.   In that way we could expose
> the standard  system flags to the explicit scoping management.   That way
> systems that  support shared folders can allow the application to specify
> the scoping  for flags on messages in the folder.   Call center
> management, help desk  applications etc have wanted this capability for
> awhile.   Don't know if I want to write that, but it would be cool.

I'm reluctant to expose any existing IMAP data through the annotation
mechanism (e.g. having an annotation that returns the current set of
message flags or the ENVELOPE etc). Since there's already a way to get to
this data there's no need for it in an annotation.

What you're proposing above is more of a redifinition of the existing flags
and I think that should be handled as a completely separate annotation
mechanism rather than being tied to the existing IMAP flags.

--
Cyrus

From: Steve Hole <[email-masked]>
Date: Fri, 23 Jul 1999 13:11:12 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: per-part message flags (was: Oslo WG meeting notes)
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999 14:11:56 -0400 Barry Leiba <[email-masked]> 
wrote:

> Just as we have the issue of per-user and global message flags, we have 
> the 
> same issue of per-user and global annotations.  Except, unlike with message
> flags, I think we must answer the question explicitly.  That is, I think we
> must provide a definitive answer to the question of whether a particular
> annotation is user-specific or global.  Otherwise we'll have an interoperability
> disaster.

You're right, we must.   

** Begin semi-serious hypothesizing **

In fact, with some clever thinking we might be able to allow scoping 
management to be explicit, and have the standard per-message flags exposed 
as part of the annotation data.   In that way we could expose the standard 
system flags to the explicit scoping management.   That way systems that 
support shared folders can allow the application to specify the scoping 
for flags on messages in the folder.   Call center management, help desk 
applications etc have wanted this capability for awhile.   Don't know if I
want to write that, but it would be cool.

** End semi-serious hypothesizing **

Cheers.   

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 23 Jul 1999 14:11:56 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: per-part message flags (was: Oslo WG meeting notes)
Sender: [email-masked]

> but soon). There will be an annotation 'hierarchy' that mimics the
> bodystructure of the message thus allowing per-part annotations. A 'flags'
> entry could then be defined in the spec with well-defined syntax for doing

Yes, that'd be perfect; I hadn't thought the ANNOTATE extension was going 
to have (effectively) per-part annotations.  Sure, with annotations, a flag 
just becomes a special case.

> per-part flags. Of course there is a major problem of how to handle
> per-user per-part flags for shared mailboxes and that's going to require

Just as we have the issue of per-user and global message flags, we have the 
same issue of per-user and global annotations.  Except, unlike with message
flags, I think we must answer the question explicitly.  That is, I think we
must provide a definitive answer to the question of whether a particular
annotation is user-specific or global.  Otherwise we'll have an interoperability
disaster.

Evil Barry, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Fri, 23 Jul 1999 08:43:03 -0600
To: Cyrus Daboo <[email-masked]>
Subject: Re:  per-part message flags (was: Oslo WG meeting notes)
Cc: Barry Leiba <[email-masked]>, IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999 10:38:21 -0400 Cyrus Daboo <[email-masked]> wrote:

> Of course there is a major problem of how to handle
> per-user per-part flags for shared mailboxes and that's going to require
> some careful design.

That's why Barry is evil :-)   Actually, Barry's not evil, he's quite a 
nice guy.   Just his ideas are evil.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 23 Jul 1999 10:38:21 -0400
From: Cyrus Daboo <[email-masked]>
To: Steve Hole <[email-masked]>, Barry Leiba <[email-masked]>
cc: IMAP Extensions Working Group <[email-masked]>
Subject: Re:  per-part message flags (was: Oslo WG meeting notes)
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Fri, Jul 23, 1999 8:22 AM -0600 Steve Hole
<[email-masked]> wrote:

> There are certainly applications for per-part flags.   If I implement 
> annotations, a general mechanism for per-message metadata, then I'm not 
> keen to do this as another extension as well.   It is arguable that 
> annotations would be more difficult to implement, but I'm not sure that 
> that is true -- at least for our server.   I have a hard time thinking of 
> the architecture of other servers, so I admit that similarity of 
> implementation may not be true for other servers.    When I think about 
> how to do either of these things in our server, ANNOTATE is only slightly 
> harder than per-part flags, but is much more flexible and general.
> 
> If we wanted to do this, I would propose some kind of profiled use of 
> ANNOTATE.   Much like the "standard options" in the ACAP Options dataset 
> class.

That's indeed what I'm planning on including in the first cut of the
ANNOTATE draft that Randy and I are working on (well he's not seen it yet -
but soon). There will be an annotation 'hierarchy' that mimics the
bodystructure of the message thus allowing per-part annotations. A 'flags'
entry could then be defined in the spec with well-defined syntax for doing
per-part flags. Of course there is a major problem of how to handle
per-user per-part flags for shared mailboxes and that's going to require
some careful design.

--
Cyrus

From: Steve Hole <[email-masked]>
Date: Fri, 23 Jul 1999 08:22:15 -0600
To: Barry Leiba <[email-masked]>
Subject: Re:  per-part message flags (was: Oslo WG meeting notes)
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

On Fri, 23 Jul 1999 08:49:48 -0400 Barry Leiba <[email-masked]> 
wrote:

> OTOH, I don't see a reason not to have "part flags", just as we have 
> folder flags and message flags.  This is distinct from the need for
> annotations.  I can see several uses for part flags.  For instance,
> suppose you send me 10 presentation slides, as 10 separate JPEG images.
> I might want to flag the one with a particular pie chart as "\flagged",
> because it's the one that's especially interesting to me.  I also might
> want to know which of the JPEG images I've "\seen" and which I haven't, 
> as I'm poking my way through your presentation.

You are an evil, evil man :-)    

There are certainly applications for per-part flags.   If I implement 
annotations, a general mechanism for per-message metadata, then I'm not 
keen to do this as another extension as well.   It is arguable that 
annotations would be more difficult to implement, but I'm not sure that 
that is true -- at least for our server.   I have a hard time thinking of 
the architecture of other servers, so I admit that similarity of 
implementation may not be true for other servers.    When I think about 
how to do either of these things in our server, ANNOTATE is only slightly 
harder than per-part flags, but is much more flexible and general.

If we wanted to do this, I would propose some kind of profiled use of 
ANNOTATE.   Much like the "standard options" in the ACAP Options dataset 
class.

Cheers.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Fri, 23 Jul 1999 08:49:48 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: Oslo WG meeting notes
Sender: [email-masked]

Steve, thanks for the summary, and thanks also to Alexey and Nick,
who filled me in offline.

> > > *** Transcoding Request
> > > - assertion that there are substantial interoperability issues
> > > - better dealt with by picking standardized represention of content-type
> 
> The concensus was that expecting servers to implement elaborate
> transcoding facilities, it would be much better if the VPIM folks could
> settle on a reasonable small set of mandatory or recommended to implement.

I agree with that as far as it goes, except that it only applies to the
case of using transcoding with VPIM, and that it assumes that every
device is able to implement the mandatory set.

When we first started talking about transcoding, I saw it (and still see
it) as a way to, say, ask for an image in a different format, to ask for
a video with fewer frames, to ask for an OCR analysis of a fax, and stuff
like that.  Suppose I have a handheld that does 256 colours on a 200x200
screen.  It does me little good to transfer a 1024x768 image with 64K 
colours.  WIBNI I could ask the server (assuming support; yes, this is a
nasty issue) to convert the image to something I could use, which wouldn't
take so long to download over my cellular link that's giving me an effective
transfer rate of only a few hundred bytes per second?

Maybe you sent me a fax of a brochure, with lots of pictures and some text.
What I need right now are the details of the conference -- dates, location,
topics.  I don't need to see the fax image; I want it put through OCR and
I want to get the results as text on my handheld.  Cool.

I think it's useful to have such capability, and I think it's worth discussing
how we might do it in an interoperable way.  The tough bits will be defining
the various transcodings that can be done, how to list them, how to specify
them, how to add more, and so on.  The basic mechanism shouldn't be terribly
controversial.

> > > *** Message length indication
...
> VPIM would like to have an indication of the length of a part in other
> units ie. seconds for sound, pages for fax etc. 

Ah, right; I didn't recognize it from the name.  I remember some discussions
about that.

> have anything to do with IMAP *except* that it is yet another new
> Content-{mumble} header that is a pain in the ass to retrieve via IMAP.

Yeah, this, though, is something we *should* work on: a better, more easily 
extended way to return the content-xxx headers.  The problem is that a client
has to "fetch bodystructure", figure out all the part IDs, and then fetch
"body[1.2.5.mime]" for each part.  Or we have to extend the bodystructure
response for each new item, and that gets icky fast.

My colleague, Wolfgang Segmuller, had once proposed having a "fetch mimestructure"
sort of thing, which parallels the bodystructure but which returns all the
mime headers for the parts in the same way that, say, content-type parameters
are returned now.  So "fetch bodystructure" returns a set of nested, parenthesized
part descriptors, and "fetch mimestructure" would return a set of similarly
nested, parenthesized part header-lists.

> > > *** Body part read indication
... 
> The requirement itself was called into question.   The premise for the
> requirement was that one body part was the "distinguished" body part of
> the message and reading it really indicates that the message has been
> "seen" by the user. 

Ah, right... from that aspect I agree.

OTOH, I don't see a reason not to have "part flags", just as we have 
folder flags and message flags.  This is distinct from the need for
annotations.  I can see several uses for part flags.  For instance,
suppose you send me 10 presentation slides, as 10 separate JPEG images.
I might want to flag the one with a particular pie chart as "\flagged",
because it's the one that's especially interesting to me.  I also might
want to know which of the JPEG images I've "\seen" and which I haven't, 
as I'm poking my way through your presentation.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Thu, 22 Jul 1999 15:08:10 -0600
To: Barry Leiba <[email-masked]>
Subject: Re: Oslo WG meeting notes
Cc: IMAP Extensions Working Group <[email-masked]>
Sender: [email-masked]

Woops ... sorry Barry, I tuned out there for a second.   Looked at the 
wrong mailing list.

On Tue, 20 Jul 1999 09:20:39 -0400 Barry Leiba <[email-masked]> 
wrote:

> There are a few items here that are sufficiently brief that I'd like a 
> bit more information.
> 
> > *** Transcoding Request
> > - assertion that there are substantial interoperability issues
> > - better dealt with by picking standardized represention of content-type

The concensus was that expecting servers to implement elaborate 
transcoding facilities, it would be much better if the VPIM folks could 
settle on a reasonable small set of mandatory or recommended to implement.
I offer no opinion on whether this is a valid view or not, I simply 
summarize the conversation.

> > *** Message length indication
> > - assertion that this is not an IMAP issue - it is MIME issue
> 
> What *is* this issue?

VPIM would like to have an indication of the length of a part in other 
units ie. seconds for sound, pages for fax etc.   We simply noted that 
this information, if added as proposed, is a new MIME header and didn't 
have anything to do with IMAP *except* that it is yet another new 
Content-{mumble} header that is a pain in the ass to retrieve via IMAP.
 
> > *** Body part read indication
> > - assertion that there are other ways to do this
> 
> Again, a summary?  What other ways are there to do this?

The requirement itself was called into question.   The premise for the 
requirement was that one body part was the "distinguished" body part of 
the message and reading it really indicates that the message has been 
"seen" by the user.   It was noted that advice in the message headers that
indicate which part is distringuished, thus providing advice to the client
on when to explicitly set the seen flag is (perhaps) a better approach.   
In any event, the concensus was to punt this back for further thought.

If push comes to shove, this requirement could be satisfied by ANNOTATE.

My personal opinion is that this requirement was an attempt to cure a 
symptom that most IMAP clients allow the implicit SEEN flag setting to 
occur on messages as a result of fetching any body part.   For the most 
part this is OK and saves round trips.   It doesn't do what the VPIM folks
want to do though.   I think that really this is client behaviour problem 
and that providing advice through a header (pick your RFC822/MIME header 
candidate) would be sufficient to solve the problem rather than making 
this particular extension to the protocol.

Cheers.
---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Tue, 20 Jul 1999 12:17:36 -0400
From: John Stracke <[email-masked]>
To: [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

Steve Hole wrote:

> > That is a point.  On the other hand, XML parsers can be pretty
> > small--I've
> > written one that takes up only about 50K--and they're pretty common these
> > days; many MUAs will already have one in the program somewhere.
>
> A validating parser?

No.  I agree that a validating parser is likely to be heavier than you need.  On
the other hand, it may be the case that you don't need validation for a property
model, since virtually everything interesting is going to be inside the property
elements, which the DTD can't cover anyway.  (Bias alert: I don't think validating
parsers ever make sense, since a robust app is going to have to do its own
double-checking anyway.)

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Date: Tue, 20 Jul 1999 09:20:39 -0400
From: Barry Leiba <[email-masked]>
Organization: Internet Messaging Technology; TR2_Xagent=WATSON
To: IMAP Extensions Working Group <[email-masked]>
Subject: Re: Oslo WG meeting notes
Sender: [email-masked]

There are a few items here that are sufficiently brief that I'd like a 
bit more information.

> *** Transcoding Request
> - assertion that there are substantial interoperability issues
> - better dealt with by picking standardized represention of content-type

Can someone summarize the discussion?  In particular, how does "picking 
[a] standardized represen[ta]tion" address the issue of, say, sending a 
high-res, high-colour image on a low-bandwidth connection to a device that 
can only display 16 colours in low-res?  I'd like to get some idea of what
people were saying on this issue.

> *** Message length indication
> - assertion that this is not an IMAP issue - it is MIME issue

What *is* this issue?

> *** Body part read indication
> - assertion that there are other ways to do this

Again, a summary?  What other ways are there to do this?

Thanks.  Sorry I couldn't be there.  :-(

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

From: Steve Hole <[email-masked]>
Date: Mon, 19 Jul 1999 17:46:01 -0600
To: John Stracke <[email-masked]>
Subject: Re: Annotations: alternate data model
Cc: [email-masked]
Sender: [email-masked]

On Mon, 19 Jul 1999 17:52:44 -0400 John Stracke <[email-masked]> wrote:

> That is a point.  On the other hand, XML parsers can be pretty 
> small--I've
> written one that takes up only about 50K--and they're pretty common these
> days; many MUAs will already have one in the program somewhere.

A validating parser?   As soon as you make it validating it gets both much
bigger and much slower.   This may more may not be an issue, but they are 
certainly not without cost.

> > I'm not sure we want to
> > lay this burden on IMAP servers and clients.
> 
> To me, what it comes down to is: can you come up with anything else that does
> what you need (structured data, internationalization, clean namespaces for
> properties) and costs less?

An alternate model is a subset of what ACAP does.   It has the advantage 
of an existing IMAP like syntax and semantic that both IMAP clients 
servers are familiar with.
 
> Of course, there are bits of XML that may not be worthwhile--for example, the
> requirement that any XML parser be able to grok the internal DTD gets a bit
> annoying.  But you could probably specify that XML documents used by ANNOTATE
> must not include an internal DTD (that'd probably cut your minimal parser size
> in half).

Exactly.   A well-formed parser like expat is not too big, but it still 
seems like a lot for what we want to do.

The biggest issue is that the stuff that is pushed onto the server is 
semantically owned by the client.   The server really doesn't need to know
anything about the data -- it is simply a blob.   This is true for 
everything but "magic" metadata supplied by the server, in which case a 
prearranged semantic agreement is made.   This was dealt with in ACAP 
using either standard options or ACAP dataset class specifications.   Even
that seems somewhat heavy to me.
 
Cheers.

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Mon, 19 Jul 1999 16:55:23 -0600
To: IMAP Extensions Working Group <[email-masked]>
Subject: Summary of actions from Oslo WG meeting
Sender: [email-masked]

Here is a summary of the actions resulting from the Oslo meeting.
---
A - Pete Resnick - to post strawman wg milestones based to list for
    inclusion in charter.

A - Pete Resnick - to post charter to IESG for approval as working
    group. 

A - Cyrus Daboo - raise issue of multiple views on list with a summary
    of discussion at Oslo.

A - Cyrus Daboo - raise issue of dynamic views on list with a summary of
    dicussion at Oslo.

A - Cyrus Daboo - change spec to resolve VIEW SEARCH / UID SEARCH
    inconsistency.

A - Mark Crispin - publish new version of original SORT extensionas an
    historical specification.

A - Mark Crispin, Cyrus Daboo - publish a new SORT2 extension that uses
    the VIEW framework.

A - Mark Crispin - raise issue of additional threading algorithms for
    threading extensions.  Includes definition of mechanism for
    requesting desired threading mechanism.

A - Mark Crispon - publish a new extended THREAD draft for discussion on
    the list.

A - John Myers - publish a new version of the ACL extension that
    includes feedback obtained from previous IMAPext sessions.

A - Mark Crispin - raise issue of expressing access semantics that
    reflect underlying filesystem and/or store access control semantics
    on list.   Expressed as a set of requirements.

A - Cyrus Daboo, Randy Gellens - publish mailbox annotations extension
    draft for discussion on list.

A - Cyrus Daboo - raise issue on usefulness of mailbox level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

A - Cyrus Daboo - raise issue on usefulness of store level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

A - Mike Gharns - publish LANGUAGE as it is now modulo minor changes
    received via the list.

A - Mike Gharns, Mark Crispin and others to work on full internationalization
    framework for doing extension work in the future and making sure that
    all working group items are internalization friendly.   Go to the list
    to determine whether or not there are milestones for this work in the
    wg charter.

A - Randy Gellens, Stewart McRae, Glenn Parsons - publish BINARY fetch
    extension for discussion on list.

A - Mike Gharns - publish updated draft of CHILD for discussion on the
    list. 

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

From: Steve Hole <[email-masked]>
Date: Mon, 19 Jul 1999 16:47:52 -0600
To: IMAP Extensions Working Group <[email-masked]>
Subject: Oslo WG meeting notes
Sender: [email-masked]

Notes for the IMAP Extensions Working Group at the 45th IETF meeting in
Oslo Norway, July 15, 1999.

WG Chair - Pete Resnick <[email-masked]>
Mailing List - <[email-masked]>

Notes - Steve Hole <[email-masked]>

Viewing the notes looks best in outline-mode of Emacs (if you care).

Action items identified during the working group are tagged with a
leading "A", followed by the action item owner (victim) and a
description of the deliverable.

A separate summary of action items will be posted to the list as a
separate document.

* Agenda bashing:
** Charter bashing
** View/sort/thread
** ACL
** Annotations
** ID
** Language
** VPIM
** Other Issues

*** list rathole
- we seek to avoid all discussion on extensions to the LIST command because
  it is a gigantic rathole.   This will be discussed in future events.

* WG Charter Bashing

** reviewed charter with exception of milestones
** charter accepted for use as a working group
** We will resolve milestones at end of meeting (if time) but otherwise on list.

A - Pete Resnick - to post strawman wg milestones based to list for
    inclusion in charter.
A - Pete Resnick - to post charter to IESG for approval as working
    group. 

* View extension - Cyrus Daboo
** Review of existing draft and proposal

- goal is to provide a subsetting facility for IMAP
- new commands "VIEW SET" and "VIEW"
- result is to set a new context that results in a set of "view specifiers"
  that allows the client to access messages based on the specifiers (rather
  than sequence number and/or uid.
- new data item for FETCH command named "VIEW"
- new VIEW untagged response 

** Is it worthwhile to proceed?
- good concensus to proceed

** Overloaded SELECT
- Mark C proposes an additional extension that is VIEW extended version
  of SELECT/EXAMINE
- concensus to add this to the proposal
- John M notes that this prevents getting EXISTS prior to issuing a VIEW

** Support for multiple VIEWS
- very expensive for the server implementors
- will clients actually use it?
  - there are examples of how a client might use it.
  - some vendors clearly expressed a desire to have it.
- there are other workarounds (multiple connections, refining criteria
  on reissued VIEW)
- punt issue to list

A - Cyrus Daboo - raise issue of multiple views on list with a summary
    of discussion at Oslo.

** Dynamic views - yes or no?
- concensus that we want dynamic insertion into the view.
- do we want dynamic removal from the view?
  - difficult because proper UI behaviours are debatable
  - discussion on whether behaviour could be asked for
  - discussion on relative difficulty of supporting this in server
  - assertion that client MUST be able to specify the static vs. dynamic
    notification behaviour
  - breakout of technical issues on what information a client has to have
    to be able to deal with removal

A - Cyrus Daboo - raise issue of dynamic views on list with a summary of
    dicussion at Oslo.

** Issues with VIEW SEARCH
- assertion that VIEW SEARCH is inconsisten UID SEARCH
- there is an easy fix to the spec to deal with this that Cyrus will make

A - Cyrus Daboo - change spec to resolve VIEW SEARCH / UID SEARCH
    inconsistency. 

** VIEW with SORT
- original proposal by Mark Crispin to publish as
  historic/informational/experimental 
- extensions to original SORT with additional sort keys and better
  defined subject sort methodology.

A - Mark Crispin - publish new version of original SORT extensionas an
    historical specification.
A - Mark Crispin, Cyrus Daboo - publish a new SORT2 extension that uses
    the VIEW framework.

** VIEW with THREADING
- create a THREAD extension based on VIEW
- Mark C reviews his existing THREAD implementation

A - Mark Crispin - raise issue of additional threading algorithms for
    threading extensions.  Includes definition of mechanism for
    requesting desired threading mechanism.

A - Mark Crispon - publish a new extended THREAD draft for discussion on
    the list.

* ACLs - John Myers
** Issues with existing proposed standard described in RFC2086
- impose more restrictions on server semantics
- identifier namespace for groups
- difficulty in expressing underlying access semantics via ACL (ie. UNIX
  access modes via ACLs)

A - John Myers - publish a new version of the ACL extension that
    includes feedback obtained from previous IMAPext sessions.

** Discussion on "expressability" of ACLs
- issues with how clients can handle expression of tied rights etc.
- a lot of discussion on how it might be possible to support
  requirements.
- assertion that "mapping" of rights was a rathole in other protocol
  work.

A - Mark Crispin - raise issue of expressing access semantics that
    reflect underlying filesystem and/or store access control semantics
    on list.   Expressed as a set of requirements.

* Annotate extension - Cyrus Daboo

** Strawman model
- allow clients and servers to add metadata to messages
- add FETCH ANNOTATION item
- add STORE +ANNOTATION
- add support for search and sort on annotation

** Issues
*** Is this of interest?
- good concensus that this is useful

*** Is this mechanism acceptible?
- good concensus that it is a good strawman model for a draft that
  addresses mailbox annotations

*** Extend to include mailbox and server annotations?
- mailbox sounds interesting
- server may be interesting
- resolution to be taken to list

*** Are ACLs on annotations too complex for now?
- yes

A - Cyrus Daboo, Randy Gellens - publish mailbox annotations extension
    draft for discussion on list.

A - Cyrus Daboo - raise issue on usefulness of mailbox level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

A - Cyrus Daboo - raise issue on usefulness of store level
    annoations.   Are they to be considered in scope for the annotations
    work in the working group.

* Client ID - Tim Showalter (in absensia)

** Issues
*** Do we want to do it?
- *very* useful for tracking
- assertion that some people will implement it no matter what
- it is open to abuse (restrictions by server for a particular client set)

*** Should it be in the scope of the working group?
- it will not be discussed within the working group
- discussion to the IMAP - not IMAPEXT working group

* LANGUAGE - Mike Garhns

** Issues
*** There are implementations of existing draft
- the number of implementations is not large (apparently)

*** Is LANGUAGE general enough?
- it addresses one part of localization
- doesn't address internationalization and other localization issues

** Solution
- discussion about a full framework that has more of the complete work
  that would subsume the functionality of LANGUAGE later on.

A - Mike Gharns - publish LANGUAGE as it is now modulo minor changes
    received via the list.

A - Mike G., Mark C and others to work on full internationalization
    framework for doing extension work in the future and making sure that
    all working group items are internalization friendly.   Go to the list
    to determine whether or not there are milestones for this work in the
    wg charter.

* VPIM Extensions - Glen Parsons

** Review of existing draft
- draft-ema-vpim-imap-01.txt 

** Where should it be discussed (which working group)?
- concensus that the parts that are general IMAP functionality should be
  discussed in IMAP extensions.
- VPIM specific stuff goes into VPIM.

** Issues
- assertion that there is danger about doing specific extensions to
  support a particular application ie. VPIM
- resolved to try to make sure that we take a stance of general
  applicability to IMAP.

*** Binary Attachment Transfer
- pull a binary object from the store (remove encodings)
- good concensus that this is both generally applicable and should be
  addressed by this group

A - Randy Gellens, Stewart McRae, Glenn Parsons - publish BINARY fetch
    extension for discussion on list.

*** External Reference
- may be applicable to other applications
- security issues raised

*** Transcoding Request
- assertion that there are substantial interoperability issues
- better dealt with by picking standardized represention of content-type

*** Streaming Audio Attachments
- assertion that PARTIAL support is sufficient for this
- we will not deal with this

*** Message length indication
- assertion that this is not an IMAP issue - it is MIME issue
- we will not deal with this

*** Body part read indication
- assertion that there are other ways to do this
- we will not deal with this

* Other Extensions
** Child mailbox draft
*** Issues
- should we continue with this?
- recommendation to come up with a general mechanism for handling LIST
  extensions in general.

A - Mike Gharns - publish updated draft of CHILD for discussion on the
    list. 

---
Steve Hole
Messaging Direct
Mailto:[email-masked]
Phone: 780-424-4922

Date: Mon, 19 Jul 1999 17:52:44 -0400
From: John Stracke <[email-masked]>
To: [email-masked]
Subject: Re: Annotations: alternate data model
Sender: [email-masked]

Cyrus Daboo wrote:

> > (Of course, this may not make as much sense in IMAP as in WebDAV, where
> > most of the protocol information is carried in XML in the first place.)
>
> This is the issue. WebDAV has everything wrapped up in an XML document. It
> requires XML parsers on both the server and client.

That is a point.  On the other hand, XML parsers can be pretty small--I've
written one that takes up only about 50K--and they're pretty common these
days; many MUAs will already have one in the program somewhere.

> I'm not sure we want to
> lay this burden on IMAP servers and clients.

To me, what it comes down to is: can you come up with anything else that does
what you need (structured data, internationalization, clean namespaces for
properties) and costs less?

Of course, there are bits of XML that may not be worthwhile--for example, the
requirement that any XML parser be able to grok the internal DTD gets a bit
annoying.  But you could probably specify that XML documents used by ANNOTATE
must not include an internal DTD (that'd probably cut your minimal parser size
in half).

Up to you.  I don't know enough about how IMAP is used to be able to figure
the tradeoffs; I just know XML.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Date: Mon, 19 Jul 1999 17:33:45 -0400
From: Cyrus Daboo <[email-masked]>
To: John Stracke <[email-masked]>, [email-masked]
Subject: Re: Annotations: alternate data model
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

Hi John,

--On Thu, Jul 15, 1999 2:27 PM +0200 John Stracke <[email-masked]> wrote:

> The strawman annotation model that was presented suggested a basic
> name/value data model, but also mentioned the possibility of wanting to
> permit values to be large binary blobs.  Rather than develop a new
> syntax for doing this, you might want to adopt something like the WebDAV
> property model, in which a property is an XML element.  The name of the
> element becomes the name of the property, and you get to use all the
> features of XML (structured data, internationalization, namespaces,
> etc.).

I had another look at the WebDAV RFC after your comments and there are some
interesting things there that could be applied to ANNOTATE. But...

> (Of course, this may not make as much sense in IMAP as in WebDAV, where
> most of the protocol information is carried in XML in the first place.)

This is the issue. WebDAV has everything wrapped up in an XML document. It
requires XML parsers on both the server and client. I'm not sure we want to
lay this burden on IMAP servers and clients.

Though not being a WebDAV/XML expert I'm certainly open to suggestions as
to how this might be applied to ANNOTATE.

--
Cyrus

Date: Thu, 15 Jul 1999 14:27:27 +0200
From: John Stracke <[email-masked]>
To: [email-masked]
Subject: Annotations: alternate data model
Sender: [email-masked]

(I'm sitting in the BOF right now, but this idea is both relatively
unimportant and potentially inflammatory, so I'm not going to waste
face-to-face time.  :-)

The strawman annotation model that was presented suggested a basic
name/value data model, but also mentioned the possibility of wanting to
permit values to be large binary blobs.  Rather than develop a new
syntax for doing this, you might want to adopt something like the WebDAV
property model, in which a property is an XML element.  The name of the
element becomes the name of the property, and you get to use all the
features of XML (structured data, internationalization, namespaces,
etc.).

(Of course, this may not make as much sense in IMAP as in WebDAV, where
most of the protocol information is carried in XML in the first place.)

I'm not on this list, so, if you want to flame me, you'll have to
CC: me.  I probably won't flame back, though, 'cause I'm not certain
that I'm right; I just wanted to offer some cross-pollination.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

Date: Thu, 08 Jul 1999 02:05:59 +0400
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>, [email-masked]
CC: Yuri Demchenko <[email-masked]>
Subject: Re: Agenda due today
Sender: [email-masked]

Alexey Melnikov wrote:

> Mark Crispin wrote:
>
> > On Fri, 2 Jul 1999, Alexey Melnikov wrote:
> > > Probably we should discuss LANGUAGE extension.
> >
> > I propose that we form a small e-mail working sub-group of people
> > interested this issue, rather than spend the limited time in Oslo.  The
> > Oslo meeting should just mention the existance of the sub-group and the
> > mailing list for it.
> >
> > This is too complex and too important of an issue to be tossed into the
> > agenda and made to compete with the other issues already in the agenda.
> >
> > I will oppose any "quick and dirty" proposal for LANGUAGE.  We have to do
> > this right, and doing it right requires careful consideration from all of
> > us.
> >
> > We need to consider localization, internationalization, and
> > mulilingualization; and from these draw up a list of desired
> > functionalties.  Among other things, we need to establish a transition
> > mechanism from ASCII and charsets to pure UTF-8.
> >
> > I have no problem with a separate face-to-face meeting of people
> > interested in LANGUAGE at Oslo.
>
> I don't mind.
>
> Let me know about date and time for LANGUAGE meeting. (BTW, I've recently
> submitted SMTP LANG draft, we may discuss it as well). I will be in Oslo all
> week.

Mike will be in Oslo as well, so he will probably agree with me that we have to
discuss LANGUAGE and all related problems.

Alexey

P.S. I will be offline from Friday up to Sunday, could we arrange this meeting
now?

Date: Mon, 28 Jun 1999 11:14:00 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Mike Macgirvin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

My only comment about multiple simultaneous views is that this makes VIEW much
more complicated to implement; and as such presents a barrier to prospective
implementors.  It may also contribute to the ongoing myth that IMAP is an
expensive service to have on a machine.

Nevertheless, this is just an observation and I don't oppose your proposal.
Please bring it up at Oslo.

Date: Mon, 28 Jun 1999 14:38:06 -0400
From: Cyrus Daboo <[email-masked]>
To: Mike Macgirvin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Hi Mike,

--On Monday, June 28, 1999, 10:56 AM -0700 Mike Macgirvin
<[email-masked]> wrote:

> This appears to have the side effect of limiting you to one view. Multiple
> active views would require extensive client polling, and the notification
> events would only be active on one of them. 
> 
> I'd like to propose a modest enhancement, where the client can provide a
> (client generated) view-id, and subsequent changes to that view are tagged
> with the view-id. This permits multiple active views. Granted, there is
> server overhead involved, but this is the price of moving it off the
> client in the first place. Having the client generate an ID is better
> than having to match an untagged response with a search string. 

Multiple views would be nice. I thought of doing something similar too.
However, I concluded that the added complexity of handling multiple views
is too much for now. It requires a lot more than just modifying EXISTS.

One major problem is that messages can be in more than one view. One way to
handle this would be to redefine the 'position' syntax to be a list of
'view number'/'view position' pairs. For example, an EXPUNGE for a message
in view #0001 and view #0003 would end up as:

a EXPUNGE
* 1 EXPUNGE 1234 ((0001 1)(0003 4))
a OK

My personal feeling is to keep VIEW simple for now and see how
implementation experience goes. There's no reason why later we can't define
a new command to deal with multiple named views and redefine the existing
VIEW syntax appropriately. e.g. 'VIEW SET' would be augmented by a 'VIEW
NAMEDSET' command that could redfine the 'position' formal syntax item to
be an S-Expression list (or whatever), and require a view name in addition
to the sub-command in a VIEW command.

--Cyrus

Date: Mon, 28 Jun 1999 13:16:45 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Hi folks,
A new internet draft is available at:

<http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>

This is the first cut at moving towards a standardised sorting mechanism
for IMAP. The extension proposed in this draft is actually a more general
extension that is used to allow a client to operate on a sub-set of
messages (as determined right now by an IMAP SEARCH command) as opposed to
the entire set of messages in the mailbox.

Basically this extension introduces a couple of new commands, together with
some new responses, including a new FETCH item called 'VIEW' which is the
message's position in the 'sub-set' or 'view'. Clients can then access
messages by their view position using a new VIEW command that takes FETCH
(and other commands) as arguments (inthe same way as the UID command
already present in IMAP4).

It is proposed that a future SORT extension will be used with the VIEW
mechanism to allow sub-setting of sort results and to allow clients to
access the messages in sorted order as opposed to sequence number order.
Thus this draft represents the first step towards the goal of a sort
command acceptable to all - hopefully!

BTW that the VIEW mechanism can be used with other types of sub-setting we
might want to think about in the future (e.g. message threading based on
message-id/in-reply-to etc).

Note that this document proposes a mechanism different from that discussed
by various groups at recent IETF and IMC interop meetings. I can post a
list of reasons why we feel this approach is better if there is interest.

--Cyrus Daboo

Date: Mon, 28 Jun 1999 10:56:26 -0700
From: Mike Macgirvin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

This appears to have the side effect of limiting you to one view. Multiple
active views would require extensive client polling, and the notification
events would only be active on one of them. 

I'd like to propose a modest enhancement, where the client can provide a
(client generated) view-id, and subsequent changes to that view are tagged
with the view-id. This permits multiple active views. Granted, there is
server overhead involved, but this is the price of moving it off the client
in the first place. Having the client generate an ID is better than having
to match an untagged response with a search string. 

        C: A143 VIEW SET 0001 SEARCH FROM "Smith"
        S: * 172 EXISTS 0001 23
        S: A143 OK VIEW SET completed
	C: A144 VIEW SET 0002 SEARCH FROM "Myboss"
	S: * 172 EXISTS 0001 23 0002 6
	S: A144 OK VIEW SET completed

It probably isn't necessary that the results be chained in the EXISTS
response, i.e. 

	S: 172 EXISTS 0001 23
	S: 172 EXISTS 0002 6

would be just fine. 

This would alter other responses appropriately. This way mailbox events can
trigger updates of any active views.
Thinking one step further, something to shut down an active view would
likely be desirable in this model. 

	C: A145 VIEW REMOVE 0001
	S: A145 OK VIEW 0001 FROM "Smith" removed

If I'm missing something obvious and all this isn't necessary, please
correct me.

Date: Mon, 28 Jun 1999 11:02:57 -0700
From: Mike Macgirvin <[email-masked]>
To: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Before somebody corrects me - yes I do know that EXISTS are untagged and
require *.

> It probably isn't necessary that the results be chained in the EXISTS
> response, i.e. 

>        S: * 172 EXISTS 0001 23
>        S: * 172 EXISTS 0002 6
............^

> would be just fine.

Date: Mon, 28 Jun 1999 12:45:31 -0700
From: Mike Macgirvin <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Mark Crispin wrote:
> 
> My only comment about multiple simultaneous views is that this makes VIEW much
> more complicated to implement; and as such presents a barrier to prospective
> implementors.  It may also contribute to the ongoing myth that IMAP is an
> expensive service to have on a machine.
> 
> Nevertheless, this is just an observation and I don't oppose your proposal.
> Please bring it up at Oslo.

I agree totally that it makes server implementation of this feature
non-trivial. Without it I think the client ends up having to work just as
hard by issuing multiple SEARCH and/or VIEW commands everytime anything in
the mailbox changes - or doing all the work client-side. We can do that
today without requiring any extensions, but it's hardly efficient. So this
draft presents a way to avoid a lot of client overhead as long as you only
define or "activate" only one view. Having worked a lot with views in the
past, one is not very typical. The bell curve fits around 5 and 20 at least
on INBOX and it's reasonable for a human to want to have all their views
active in the sense that message counts are propogated in as near to real
time as possible. 

I'll see if somebody else from here will be at Oslo and ask that they
present these arguments - unfortunately, I have other obligations.

Date: Mon, 28 Jun 1999 17:52:36 -0400
Reply-To: [email-masked]
From: Tony Hansen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Cyrus Daboo wrote:
> 
> A new internet draft is available at:
> <http://www.ietf.org/internet-drafts/draft-daboo-imap-view-00.txt>
> 
> This is the first cut at moving towards a standardised sorting mechanism
> for IMAP. The extension proposed in this draft is actually a more general
> extension that is used to allow a client to operate on a sub-set of
> messages (as determined right now by an IMAP SEARCH command) as opposed to
> the entire set of messages in the mailbox.
> 
> Basically this extension introduces a couple of new commands, together with
> some new responses, including a new FETCH item called 'VIEW' which is the
> message's position in the 'sub-set' or 'view'. Clients can then access
> messages by their view position using a new VIEW command that takes FETCH
> (and other commands) as arguments (inthe same way as the UID command
> already present in IMAP4).
> ...

Our major problem with this proposal is not an issue with the extension
itself. Instead, we have an issue with its impact on server performance
when dealing with LARGE user populations (hundreds of thousands or
millions). Each proposal such as this does increase the server load.

	Tony Hansen
	[email-masked]

Date: Mon, 28 Jun 1999 15:05:38 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: [email-masked]
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

On Mon, 28 Jun 1999 17:52:36 -0400, Tony Hansen wrote:
> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

There's a tradeoff in all of these things.  Some people consider the
functionality of VIEW to be very important, and have blocked SORT and THREAD
unless this functionality is provided.  One of their concerns is that the SORT
command uses communication bandwidth; for example, sorting a 2000 message
mailbox results in a response that is 8900 octets long.

SORT and THREAD are very important for UW since these extensions make a *HUGE*
difference in Pine performance.  So, it's important for us to get these
concerns addressed, and preferably in an extensible mechanism.

Date: Mon, 28 Jun 1999 20:28:06 -0400
From: Cyrus Daboo <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

--On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:

> Our major problem with this proposal is not an issue with the extension
> itself. Instead, we have an issue with its impact on server performance
> when dealing with LARGE user populations (hundreds of thousands or
> millions). Each proposal such as this does increase the server load.

Actually the hope for this proposal (wrt to sorting) is to REDUCE the
overall server load by removing the need for a client to download the
envelopes of all messages in order to sort them for the end-user. It should
also reduce client load and indeed allow thin-clients to present sorted or
sub-set views without having to do much work.

--
Cyrus

Date: Tue, 29 Jun 1999 00:38:15 +0000
From: steve spear <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

Can someone explain how traffic is reduced by SORT over clients that are
caching the headers and simply request messages headers they haven't seen
before?   As Tony Hansen pointed out - AT&T is trying to handle many millions
of users.  The thought of using more resources on the server instead of the
clients that are largely idle is a concern of ours.  We keep hearing about
thin-client's, but the memory available in the thin clients still boggles the
mind of those who had memory measured in Kilobytes ( not Megabytes ) 25+ years
ago.  If it makes sense we'll cheer for it,  but we'd like to understand where
the advantage is.

Steve Spear
AT&T Technology Consultant

Cyrus Daboo wrote:

> --On Mon, Jun 28, 1999 5:52 PM -0400 Tony Hansen <[email-masked]> wrote:
>
> > Our major problem with this proposal is not an issue with the extension
> > itself. Instead, we have an issue with its impact on server performance
> > when dealing with LARGE user populations (hundreds of thousands or
> > millions). Each proposal such as this does increase the server load.
>
> Actually the hope for this proposal (wrt to sorting) is to REDUCE the
> overall server load by removing the need for a client to download the
> envelopes of all messages in order to sort them for the end-user. It should
> also reduce client load and indeed allow thin-clients to present sorted or
> sub-set views without having to do much work.
>
> --
> Cyrus

Date: Mon, 28 Jun 1999 18:40:54 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: steve spear <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

On Tue, 29 Jun 1999 00:38:15 +0000, steve spear wrote:
> Can someone explain how traffic is reduced by SORT over clients that are
> caching the headers and simply request messages headers they haven't seen
> before?

Most such clients are POP clients masquerading as IMAP clients.  Consider true
IMAP clients, which don't have a cache (and may well be a kiosk or other
shared machine which shouldn't cache!), and don't want to load all those
headers.

Date: Tue, 29 Jun 1999 15:21:52 -0400
From: Barry Leiba <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

First comment:  Can we take the IMAP mailing list out of the list on
this discussion, and just hold it on the IMAPext mailing list?  It seems
silly to post the same discussion to both lists -- why do we have the
IMAPext list at all, if we're going to do that?

Other comments:
* Section 4.1 refers to an "optional" sub-command, and (a) says that 
  the  VIEW SET command selects messages that "match the results of the
  sub-command".  It doesn't make it clear what happens if there's no
  sub-command (all messages are selected, I presume).  It also doesn't
  say much about the sub-command; if "SEARCH" is the only command in
  the base spec that applies, it should probably say so, to prevent
  people from wondering what commands apply.  It might also say (which
  is also said elsewhere) that it's intended that future SORT and 
  THREAD commands may go here.

* In 4.1 (b), "c.f." is properly abbreviated "cf.", and, anyway, is the
  wrong Latin abbreviation here.  "cf." means "compare" (from the Latin
  "confer"), and I don't think you want anyone to compare what you say
  here to what's said in 4.2.  If you mean "see section 4.2", just say it.
  (Sorry... pet peeve about misuse of Latin abbreviations.)

* In the example in 4.1 (g), correct spelling of "SEARCH".

* In 4.2 you should make it clear what, if anything, it means to use a
  VIEW command without a VIEW SET being in effect.  It seems to me that
  it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
  case?).

* In 4.2, you say
    command response.  However, server implementations MUST implicitly
    include the VIEW fetch item as part of any FETCH response caused by
    a VIEW command, regardless of whether a VIEW was specified as a
    message data item to the FETCH.

  ...but you've already said that a VIEW fetch item must be included if
  a VIEW SET is in effect.  If I'm right in my previous note, then you
  probably shouldn't *also* say this.

* In 5.1.1:
    A VIEW untagged response MUST NOT be sent when no command is in
    progress; nor while responding to a FETCH, SEARCH or STORE command.

  Understandable.  But that means that a client that receives an EXISTS
  in response to a FETCH must then go issue a NOOP to get the corresponding 
  VIEW response.  Can we think of a better way?

  Also, it might not hurt to point out that IDLE can count as a command
  in progress.  But, then, maybe that's too obvious to have to mention.

* In 5.1.2:
    When the old view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message inserted into the view at
    the position given by <new>.  The view position numbers of all
    subsequent messages inthge current view are incremented.

    When the new view position number in the VIEW untagged response is
    non-zero, the effect of VIEW is a message removed from the view at
    the position given by <old>.  The view position numbers of all
    subsequent messages inthe current view are decremented.

  In both of these, I think you mean "zero" where you say "non-zero".
  Also, fix "inthge" and "inthe".
  Also also, since you explicitly talk about incrementing and decrementing
  view position numbers, perhaps you should include a paragraph about what
  happens if both the old and new positions are non-zero... which also
  require renumbering other messages.  No, *I* don't think it needs to be
  said, but, then, I'm always surprised at the interpretations that sometimes
  happen when one fails to say something.  :-)

* In the grammar:
    position         ::= number ["." number]
                         ;; position number of messages in the view
                         ;; may be hierarchical if sub-command defines
                         ;; hierarchic ordering of messages

  This makes some of the statements about "incrementing" and "decrementing"
  view positions harder to understand.  Maybe all we should say about what
  happens after a VIEW response is that "view positions of subsequent [or
  intervening] messages must be adjusted appropriately" or some such.

* Finally, just to clarify things... we'd had an extended discussion about
  whether it was reasonable to remove a message from a view, once it was
  in the view.  Problems of side-effects and such -- for instance, what 
  happens in the following case (abbreviating a little):
    c: t0 VIEW SET SEARCH UNSEEN
    s: * 25 VIEW 1234 0 4
    c: t1 VIEW FETCH 4 BODY[1]
    s: * 25 FETCH (FLAGS (\Seen) VIEW 4 BODY[1] ...
    s: t1 OK done
    c: t2 NOOP
    s: * 25 VIEW 1234 4 0    [\Seen flag caused view to change]
    s: t2 OK done

  Now, as a side-effect of the FETCH, the client can no longer use VIEW FETCH
  on this message.  Other cases are easy to imagine.  It makes VIEW FETCH of
  questionable use.

  Clearly, the decision made in writing this draft was to have messages 
  disappear from the view (during earlier discussions, some thought they 
  should not, though it came out that that makes reconnecting after connection 
  failures difficult).

  I just wanted to point out, for the record, that there were two sides to
  that discussion, and to point out, for the record, which one was adopted.
  (And, for the record, I agree with the choice.)

  But I would like to see some of these potential problems mentioned in the 
  spec.  I would also like to see some encouragement to use UIDs instead of
  view positions.  In fact, I'd go as far as to say that I don't think we
  should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
  should clearly state that UIDs are the things to use when you're using views.

Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba

Date: Tue, 29 Jun 1999 16:25:56 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Status: O
Sender: [email-masked]

First, an apology.  My contribution to this document so far has been mostly
architectural, so if I say something that doesn't fully mesh with what the
document says, keep this in mind.

> * Section 4.1 refers to an "optional" sub-command, and (a) says that
>   the  VIEW SET command selects messages that "match the results of the
>   sub-command".  It doesn't make it clear what happens if there's no
>   sub-command (all messages are selected, I presume).

I thought that VIEW SET without a command was to cancel the view.  If this
isn't specified, it should be.

>   It also doesn't
>   say much about the sub-command; if "SEARCH" is the only command in
>   the base spec that applies, it should probably say so, to prevent
>   people from wondering what commands apply.  It might also say (which
>   is also said elsewhere) that it's intended that future SORT and
>   THREAD commands may go here.

Let's talk about the wordsmithing for this at Oslo.  VIEW SET's command
argument is a command that defines a set (and, potentially, ordering) of
messages.  I agree that this needs to be well-specified, but I don't want to
tag/limit it to SEARCH/SORT/THREAD even if that's the actual situation today.

> * In 4.2 you should make it clear what, if anything, it means to use a
>   VIEW command without a VIEW SET being in effect.  It seems to me that
>   it's nonsensical (so should "VIEW FETCH" respond "NO" or "BAD" in that
>   case?).

I think that it's a BAD.

>   I would also like to see some encouragement to use UIDs instead of
>   view positions.  In fact, I'd go as far as to say that I don't think we
>   should *have* a VIEW FETCH, VIEW STORE, or VIEW COPY command, and that we
>   should clearly state that UIDs are the things to use when you're using
>   views.

You need some way to express hierarchy in a VIEW (for threading), which is why
neither sequence numbers nor UIDs are good enough.  If you use either a
sequence number or UID (I don't think that one should be preferred over the
other, beyond what technical considerations indicate), then you have to
maintain the map or some portion of it.

The whole point for VIEW FETCH and friends is so you don't need to have the
map at all.

Date: Fri, 02 Jul 1999 03:08:51 +0400
From: Alexey Melnikov <[email-masked]>
To: Mark Crispin <[email-masked]>
CC: [email-masked]
Subject: Re: Agenda due today
Sender: [email-masked]

Mark Crispin wrote:

> On Fri, 2 Jul 1999, Alexey Melnikov wrote:
> > Probably we should discuss LANGUAGE extension.
>
> I propose that we form a small e-mail working sub-group of people
> interested this issue, rather than spend the limited time in Oslo.  The
> Oslo meeting should just mention the existance of the sub-group and the
> mailing list for it.
>
> This is too complex and too important of an issue to be tossed into the
> agenda and made to compete with the other issues already in the agenda.
>
> I will oppose any "quick and dirty" proposal for LANGUAGE.  We have to do
> this right, and doing it right requires careful consideration from all of
> us.
>
> We need to consider localization, internationalization, and
> mulilingualization; and from these draw up a list of desired
> functionalties.  Among other things, we need to establish a transition
> mechanism from ASCII and charsets to pure UTF-8.
>
> I have no problem with a separate face-to-face meeting of people
> interested in LANGUAGE at Oslo.

I don't mind.

Let me know about date and time for LANGUAGE meeting. (BTW, I've recently
submitted SMTP LANG draft, we may discuss it as well). I will be in Oslo all
week.

--
Best Regards,
Alexey Melnikov
+----------------------------------------------------+
|SMTP/POP3/IMAP4/ACAP  | Epsylon Technologies, Russia|
|servers creation team |     http://www.taxxi.com    |
|----------------------------------------------------|
|Imap Development Kit (my own product)               |
|http://194.87.43.111/homerus/mail/idk/index.htm     |
|----------------------------------------------------|
|Fax (in San Diego, California): 1 (619) 8393837     |
+----------------------------------------------------+

From: "Mike Gahrns" <[email-masked]>
To: "Cyrus Daboo" <[email-masked]>, "Barry Leiba" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-daboo-imap-view-00.txt
Date: Thu, 1 Jul 1999 14:05:05 -0700
Sender: [email-masked]

> > * In 5.1.2:
> >     When the old view position number in the VIEW untagged response is
> >     non-zero, the effect of VIEW is a message inserted into the view at
> >     the position given by <new>.  The view position numbers of all
> >     subsequent messages inthge current view are incremented.
> >
> >     When the new view position number in the VIEW untagged response is
> >     non-zero, the effect of VIEW is a message removed from the view at
> >     the position given by <old>.  The view position numbers of all
> >     subsequent messages inthe current view are decremented.
> >
> >   In both of these, I think you mean "zero" where you say "non-zero".
>
> Yup, that's wrong in the document.
*** I also think that you have the order of <new> and <old> view numbers
reversed in your examples in this section relative to the definition of view
response you give in 5.1.2

Date: Thu, 1 Jul 1999 15:22:03 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Cyrus Daboo <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda due today
Sender: [email-masked]

On Fri, 2 Jul 1999, Alexey Melnikov wrote:
> Probably we should discuss LANGUAGE extension.

I propose that we form a small e-mail working sub-group of people
interested this issue, rather than spend the limited time in Oslo.  The
Oslo meeting should just mention the existance of the sub-group and the
mailing list for it.

This is too complex and too important of an issue to be tossed into the
agenda and made to compete with the other issues already in the agenda.

I will oppose any "quick and dirty" proposal for LANGUAGE.  We have to do
this right, and doing it right requires careful consideration from all of
us.

We need to consider localization, internationalization, and
mulilingualization; and from these draw up a list of desired
functionalties.  Among other things, we need to establish a transition
mechanism from ASCII and charsets to pure UTF-8.

I have no problem with a separate face-to-face meeting of people
interested in LANGUAGE at Oslo.

Date: Fri, 02 Jul 1999 01:59:51 +0400
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda due today
Sender: [email-masked]

Cyrus Daboo wrote:

> --On Thursday, July 01, 1999, 3:21 PM -0500 Pete Resnick
> <[email-masked]> wrote:
>
> > In among my mayhem, I'd forgotten that I was supposed to get an
> > agenda for the BOF in today. I'll get it in late today and hope I
> > don't get yelled at. I assume we'll spend a little time on the
> > charter, but then what's on the plate?
> >
> > I'm sending something in by 6PM CDT today (so that Marcia doesn't
> > beat me up) with or without input, so please send input ASAP.
> > Otherwise, I'll make something up.
>
> I guess we want something like:
>
> 1) Charter completion - approval of WG status
> 2) Discuss VIEW/SORT drafts (long)
> 3) Discuss ACL2 (should consult John Myers to see how much he's been able
> to do on this)
> 4) Discuss annotations (short as there's no real draft yet, but a general
> 'how should we do it' discussion would be good)
> 5) Discuss other extensions not on the 'official' charter (e.g. Client ID
> and anything else that folks want to bring up)

Probably we should discuss LANGUAGE extension.

--
Best Regards,
Alexey Melnikov

Date: Thu, 01 Jul 1999 16:29:51 -0400
From: Cyrus Daboo <[email-masked]>
To: Pete Resnick <[email-masked]>, [email-masked]
Subject: Re: Agenda due today
Originator-Info: login-id=daboo; server=imap.cyrusoft.com:431
Sender: [email-masked]

--On Thursday, July 01, 1999, 3:21 PM -0500 Pete Resnick
<[email-masked]> wrote:

> In among my mayhem, I'd forgotten that I was supposed to get an 
> agenda for the BOF in today. I'll get it in late today and hope I 
> don't get yelled at. I assume we'll spend a little time on the 
> charter, but then what's on the plate?
> 
> I'm sending something in by 6PM CDT today (so that Marcia doesn't 
> beat me up) with or without input, so please send input ASAP. 
> Otherwise, I'll make something up.

I guess we want something like:

1) Charter completion - approval of WG status
2) Discuss VIEW/SORT drafts (long)
3) Discuss ACL2 (should consult John Myers to see how much he's been able
to do on this)
4) Discuss annotations (short as there's no real draft yet, but a general
'how should we do it' discussion would be good)
5) Discuss other extensions not on the 'official' charter (e.g. Client ID
and anything else that folks want to bring up)

--
Cyrus

Date: Thu, 1 Jul 1999 15:21:27 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Agenda due today
Sender: [email-masked]

In among my mayhem, I'd forgotten that I was supposed to get an 
agenda for the BOF in today. I'll get it in late today and hope I 
don't get yelled at. I assume we'll spend a little time on the 
charter, but then what's on the plate?

I'm sending something in by 6PM CDT today (so that Marcia doesn't 
beat me up) with or without input, so please send input ASAP. 
Otherwise, I'll make something up.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (619)651-4478, Fax: (619)651-1102

From: "Mike Gahrns" <[email-masked]>
To: "Rubinstein, Dmitry" <[email-masked]>, <[email-masked]>
Subject: Re: Client ID extension
Date: Thu, 1 Jul 1999 09:45:03 -0700
Sender: [email-masked]

Dmitry writes:
> > From: Mike Gahrns [mailto:[email-masked]]
> > Given that there seems to be
> > reasonable
> > number of people who concur that this type of functionality
> > would be useful,
> > moving the extension forward should hopefully be rather
> > straight foward with
> > only minor changes needed.
>
>
> OK then, what are the needed changes? Below is the original draft for your
> reference.
Since there was a lot of concerns about the potential abuse of it and
privacy concerns, we probably should have stronger language regarding the
caveats around this to avoid potential abuse.  e.g. in the client parameter
list it states any value over and above the defined fields can be sent.  I
think you'd want a stronger privacy statement here, in case people start
sending more than the defined fields and include things like Processor ID,
MAC address etc.  (I certainly don't want to start a discussion regarding
the merits or non-merits of including this type of info, but I think it
would be wise to have strong language here)

In the security section,  it should be noted that knowing the make/type of
client/server could make it easier for hackers to exploit known
vulnerabilities with particular software.

If you cruise through the IMAP archives you'll probably find some other
comments as well.  If memory serves me correctly, I think the author, Tim
Showalter, said that he had a list of changes he wanted to incorporate.

In any event, I think any changes would be minor in nature, and would be
more along the lines of "editorial" type changes.