From tss@iki.fi Tue May 22 04:52:50 2012 Return-Path: X-Original-To: lemonade@ietfa.amsl.com Delivered-To: lemonade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A15521F85F1 for ; Tue, 22 May 2012 04:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.522 X-Spam-Level: X-Spam-Status: No, score=-108.522 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQWfFoKQs4cb for ; Tue, 22 May 2012 04:52:49 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8372F21F85C9 for ; Tue, 22 May 2012 04:52:49 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id F41581AE876B for ; Tue, 22 May 2012 14:52:47 +0300 (EEST) From: Timo Sirainen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 22 May 2012 14:52:47 +0300 Message-Id: To: lemonade@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [lemonade] URLAUTH RESETKEY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 11:52:50 -0000 > BASE.6.3.RESETKEY. RESETKEY Command .. > Any current IMAP session logged in as the user that has the mailbox > selected will receive an untagged OK response with the URLMECH = status > response code (see section BASE.7.1.URLMECH for more details about > the URLMECH status response code). This is a bit confusing. First of all, what is the purpose of sending = the URLMECH response to other clients? Can they assume that if it's = received then a RESETKEY command has been issued? Doesn't seem very = IMAPy to assume that, since it is also sent during SELECT/EXAMINE. Is it = simply to handle the cases when non-INTERNAL mechanisms are used and = they might have changed the mech-specific data? Is there really even a = need to send this if server only supports INTERNAL? And when would the message be sent? Does "will receive" mean = immediately? Before the next command? After the next command? Maybe = sometimes later? From alexey.melnikov@isode.com Thu May 24 08:22:08 2012 Return-Path: X-Original-To: lemonade@ietfa.amsl.com Delivered-To: lemonade@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC521F855B for ; Thu, 24 May 2012 08:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCOrvtix5fJ3 for ; Thu, 24 May 2012 08:22:07 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 932B921F8503 for ; Thu, 24 May 2012 08:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337872921; d=isode.com; s=selector; i=@isode.com; bh=4mZ2OuQEkYsXt76VMeFwNSIFlMYhbQQXmT9esoIrO1k=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WLxY42Y2dEkiM+z5Ay067L9Nvxw2icDan2Y114L7qKuGorAN7BIEfApxuMDChbn05VvL+S uEp0E/ByqMxxO1cmFkRVtNY0Wcgi3YgNkFWSk78xRLkRf7lAbp+XjgKcHWdKE8gTHf0TLh dxejH4MuZLdqpSQzscQfM3CjPcetbfo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 24 May 2012 16:22:01 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FBE522E.6070300@isode.com> Date: Thu, 24 May 2012 16:22:22 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Timo Sirainen References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org Subject: Re: [lemonade] URLAUTH RESETKEY X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 15:22:08 -0000 Hi Timo, On 22/05/2012 12:52, Timo Sirainen wrote: >> BASE.6.3.RESETKEY. RESETKEY Command > .. >> Any current IMAP session logged in as the user that has the mailbox >> selected will receive an untagged OK response with the URLMECH status >> response code (see section BASE.7.1.URLMECH for more details about >> the URLMECH status response code). > This is a bit confusing. First of all, what is the purpose of sending the URLMECH response to other clients? I think the purpose is to notify the client that previously issued URLAUTH keys are no longer valid. The client might want to regenerate some URLs upon seeing that. > Can they assume that if it's received then a RESETKEY command has been issued? Not necessarily. This might also be caused by some administrative interface that doesn't necessarily use IMAP. > Doesn't seem very IMAPy to assume that, since it is also sent during SELECT/EXAMINE. Is it simply to handle the cases when non-INTERNAL mechanisms are used and they might have changed the mech-specific data? Is there really even a need to send this if server only supports INTERNAL? On SELECT/EXAMINE this response code is used to advertise supported URLAUTH mechanisms. > And when would the message be sent? Does "will receive" mean immediately? Before the next command? After the next command? Maybe sometimes later? Well, if your session is in IDLE, you should receive it immediately. Otherwise sending it on the next command would be fine, unless the next command is GENURLAUTH...