Re: IMAP,ACL,NAMESPACE,Mozilla,Outlook.

Richard Bang writes:
> I have managed to get ACL and NAMESPACE to work with Mozilla, but this 
> forces me to use name spaces for shared items and this instantly 
> breaks Outlook (& Express).

Why does this break Outlook/OE?

Arnt

RE: IMAP,ACL,NAMESPACE,Mozilla,Outlook.

Hi,
> 
> Why does this break Outlook/OE?
> 
O/OE doesn't understand namespaces so I cant move the shared folders out of
the folder tree.

Currently:
"/" inbox
"/" drafts
"/" shared/fred/inbox
"/" "sent items"

But If I do:
"/" inbox
"/" drafts
"#" fred/inbox
"/" "sent items"

O/OE wont see them. Is there another way to do this that doesn't break O/OE?

Also. At any point I can share any of my folders, and there doesnt seem to
be a way to identify that the folders can be shared. So I want to be able to
have:

"/" inbox    <-mine
"/" drafts   <-mine
"/" shared/fred/inbox <- freds but I have read access
"/" "sent items" <- mine

Re: IMAP,ACL,NAMESPACE,Mozilla,Outlook.

What happens if you specify the namespaces within the folder tree?

Richard Bang writes:
> O/OE doesn't understand namespaces so I cant move the shared folders 
> out of the folder tree.
>
> Currently:
> "/" inbox
> "/" drafts
> "/" shared/fred/inbox
> "/" "sent items"

... ie. you specify that / is personal and /shared/ is shared.

> How can I do these things? When I read the spec it strongly implies 
> (to me anyway) that personal, public and shared folders must all be 
> in separate namespaces. Am I misreading it?

AFAICR, the spec does not say nonoverlapping.

RFC 2342 example 5.3 seems to be rather similar to your case.

Arnt

RE: IMAP,ACL,NAMESPACE,Mozilla,Outlook.

Hi,

I just realised my previous post may imply that I believe there is something
wrong with the protocols themselves. This is not the case and implementing
any of the protocols per se does not "break" the client.

The problem is, as Mark has often commented, that a broken client usually
results in the server being blamed. As in Mozilla if you don't have ACL.

After implementing ACL I was able with my test platfrom to correct
manipluate the shares on all the folders using a non NAMESPACE system.

However, this results in Mozilla showing all the share status but not
letting you actually share anything. To get Mozilla to share things you need
to move the shared items into a separate namespace (a namespace of shared/
doesn't cut it unfortunatly). 

I would love to be able to just declare that the fault is the client, but
this is usually futile.

I guess the soution would be for a client to see ACL and assume that it can
(at least try) to share anything for which myrights includes a (SETACL) as
this is what it means.

Regard 
Richard.

CRAMing for last call

Now that 2222bis is close to reality, I would like to push the final 
version of CRAM out as well. The two documents should be able to go 
through together, (I hope) making life easier for the RFC editor.

I have some non-substantive editorial changes that will make the 
document a bit easier to read, but these are not show stoppers. I think 
all of the last round of comments are addressed in the current draft. 
If not, I would like to hear from people, soon.

I would also like to solicit a few additional examples from anyone who 
has implemented CRAM in other than IMAP.

Finally, we need to address the issue of the MD5 "break." I have held 
off from commenting on this issue until the community has seen explicit 
evidence of the attack, and the implications of it. At this point, I 
don't know if the document deserves a writeup on the attack. Theory 
abounds, but I haven't yet seen a practical attack that works in the 
general case. We should at the least make mention of what has been 
discussed, and point to the literature, but I don't think the document 
deserves to discuss all the possible attacks. This doesn't mean to 
discourage anyone from contributing text to the Security Considerations 
section (please do).

The IMAP-EXT list has had recent discussion that points out the 
ambiguity of searching for the space (SP) separator (between the user 
id and the digest) as being the rightmost SP, so I will strengthen that 
text. Any other comments should come forth soon as I would like to run 
out the final draft at the end of next week (Oct. 8) if I can.

Re: CRAMing for last call

>>>>> "Lyndon" == Lyndon Nerenberg <lyndon <at> orthanc.ca> writes:

    Lyndon> Finally, we need to address the issue of the MD5 "break."
    Lyndon> I have held off from commenting on this issue until the
    Lyndon> community has seen explicit evidence of the attack, and
    Lyndon> the implications of it. At this point, I don't know if the
    Lyndon> document deserves a writeup on the attack. Theory abounds,
    Lyndon> but I haven't yet seen a practical attack that works in
    Lyndon> the general case. We should at the least make mention of
    Lyndon> what has been discussed, and point to the literature, but
    Lyndon> I don't think the document deserves to discuss all the
    Lyndon> possible attacks. This doesn't mean to discourage anyone
    Lyndon> from contributing text to the Security Considerations
    Lyndon> section (please do).

The security area seems to believe that hmac-md5 is still OK, at least
for now.  Especially since cram-md5 does not require much structure
for the challenge, we should discuss the issue in the security
considerations section.

Will you need agenda time at the next meeting?  If so, can you give an
estimate of how much and what we want to cover?

Thanks,

--Sam

Re: Major changes in draft-ietf-imapext-list-extensions-09

Re: Major changes in draft-ietf-imapext-list-extensions-09

 >P.S. I've just submitted revision 10 of LISTEXT. It addresses the 
issues mentioned in this message +
 > updates ABNF for the MATCHPARENT option + changes LISTEXT to only 
return \PlaceHolder/\HasSubmailboxes
 >only when MATCHPARENT is specified. It also includes some editorial 
suggestions from Arnt.

I've also fixed few minor bugs in examples (in one place \SubMailboxes 
was not accompanied by \Subscribed)

Re: Major changes in draft-ietf-imapext-list-extensions-09

>What does a response with \Placeholder or \HasSubmailboxes mean when
>MATCHPARENT is used with REMOTE but without SUBSCRIBED?  I see three
>possible answers:
>a) it means the mailbox has at least one submailbox that is remote
>b) is means the mailbox has at least one submailbox, local or remote
>c) (b), but that's the same as \HasChildren, so MATCHPARENT shouldn't be
>   allowed with just REMOTE: it should require SUBSCRIBED or some other
>   option that affects the selection criteria.
>
>IMO, the current text says (b).  Switching it to (a) would require a
>major rethink of the concept of "selected", or would effectively declare
>MATCHPARENT as having ad hoc interaction with each selection option.  I
>would just as soon go with (c) and can help with text to that effect.

I don't think interpretation c) is very useful. This seems to make
existing complex situation even more complex. Currently the draft says 
that b) is the case. If people think that a) is more appropriate, than 
the WG needs to reconsider what REMOTE selection option means.

>Depending on how that question is settled, I may have an argument that
>in response to <LIST (SUBSCRIBED MATCHPARENT) "" "%">, responses with
>the \Placeholder flag also need the \Subscribed flag to avoid
>ambiguity.

As per off list discussion with Philip, I've changed the document to say 
that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
specified. In particular, this means that they are not allowed in LIST 
responses not caused by the latest LIST command.

Philip's suggestion is that the server will send
"\Placeholder \Subscribed" in response to
<LIST (SUBSCRIBED MATCHPARENT) "" "%">.
This will mean "the mailbox is not really sibscribed, but the 
\Placeholder flag was caused by SUBSCRIBED selection option.

IMHO, this seems to be overly complex. I think my change detailed above 
would suffice, however if WG members feel otherwise, I would like to 
hear their comments.

Alexey

Re: Major changes in draft-ietf-imapext-list-extensions-09

Alexey Melnikov <Alexey.Melnikov <at> isode.com> writes:
...
>As per off list discussion with Philip, I've changed the document to say 
>that \PlaceHolder/\HasSubMailboxes is only allowed when MATCHPARENT is 
>specified. In particular, this means that they are not allowed in LIST 
>responses not caused by the latest LIST command.
>
>Philip's suggestion is that the server will send
>"\Placeholder \Subscribed" in response to
><LIST (SUBSCRIBED MATCHPARENT) "" "%">.
>This will mean "the mailbox is not really sibscribed, but the 
>\Placeholder flag was caused by SUBSCRIBED selection option.
>
>IMHO, this seems to be overly complex. I think my change detailed above 
>would suffice, however if WG members feel otherwise, I would like to 
>hear their comments.

My suggestion was not really sufficient to completely remove the
ambiguity of an unsolicited \Placeholder response**, so I support this
change.

Philip Guenther

** does an unsolicited "\Placeholder \Subscribed" response mean the
   named mailbox has subscribed submailboxes, or does it mean the named
   mailbox is subscribed and it has (possibly remote) submailboxes?
   I.e., should the response be treated as if there was an outstanding
   <LIST (SUBSCRIBED MATCHPARENT) ...> command or as if there was an
   outstanding <LIST (REMOTE MATCHPARENT) ... RETURN (SUBSCRIBED)> ?
   Either way, if the server sends that response right before the client
   sends the LIST command that doesn't match what the server did, the
   client will have no way of knowing that it should not treat that
   \Placeholder in that LIST response as working under the selection
   criteria that the client sent.