Re: I-D ACTION:draft-daboo-imap-view-00.txt

[Barry Leiba <[e-mail]>]

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  ([e-mail])
http://www.research.ibm.com/people/l/leiba