Re: [Extra] Protocol Action: 'The JMAPACCESS Extension for IMAP' to Proposed Standard (draft-ietf-extra-jmapaccess-08.txt)

[Ken Murchison <[e-mail]>]

On 3/4/24 5:25 PM, Ken Murchison wrote:
>
> Hmm.  There is an issue with returning the JMAPACCESS response code if 
> a server also wants to use the CAPABILITY response code for telling 
> the client which capabilities are available post-authentication.  The 
> IMAP grammer only allows one repsonse code in a tagged response, correct?
>
> Perhaps rather than JMAPACCESS being a response code, its just a 
> post-auth capability?
>
Actually, I just noticed that Example 2 shows the JMAPACCESS response 
code being returned in an untagged OK response.  I missed it because in 
the HTML rendering of the doc, the tagged response is on the same line 
as the untagged one.

If JMAPACCESS can be returned in either tagged or untagged responses, 
then this solves the issue with the CAPABILITY response code, and the 
work-in-progress Cyrus implementation now does this:

S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2 AUTH=LOGIN AUTH=PLAIN ENABLE ID JMAPACCESS LITERAL+ SASL_IR STARTTLS] localhost Cyrus IMAP 3.11.0-alpha0-197-g65bfbefdd server ready
C: L01 LOGIN ken {7}
S: + go ahead
C: <omitted>
S: * OK [JMAPACCESS "https://localhost/jmap  <https://localhost/jmap>"] This server is also accessible via JMAP, see RFC8620
S: L01 OK [CAPABILITY IMAP4rev1 IMAP4rev2 ACL ANNOTATE-EXPERIMENT-1 APPENDLIMIT=2147483647 BINARY CATENATE CHILDREN COMPRESS=DEFLATE CONDSTORE CREATE-SPECIAL-USE ENABLE ESEARCH ESORT ID IDLE INPROGRESS LIST-EXTENDED LIST-METADATA LIST-MYRIGHTS LIST-STATUS LITERAL+ LOGINDISABLED MAILBOX-REFERRALS METADATA MOVE MULTIAPPEND MULTISEARCH NAMESPACE NOTIFY OBJECTID PARTIAL PREVIEW QRESYNC QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE QUOTA=RES-ANNOTATION-STORAGE QUOTA=RES-MAILBOX QUOTASET REPLACE RIGHTS=kxten SAVEDATE SEARCH=FUZZY SEARCHRES SORT SORT=DISPLAY SPECIAL-USE STATUS=SIZE THREAD=ORDEREDSUBJECT THREAD=REFERENCES UIDONLY UIDPLUS UNSELECT URL-PARTIAL URLAUTH URLAUTH=BINARY WITHIN DIGEST=SHA1 NO_ATOMIC_RENAME SCAN SORT=MODSEQ SORT=UID THREAD=REFS X-CREATEDMODSEQ X-REPLICATION X-REPLICATION-ARCHIVE X-SIEVE-MAILBOX XCONVERSATIONS XLIST XMOVE] User logged in SESSIONID=<localhost-1709666786-3160805-1-5696077241981360779>


If we choose to stick with JMAPACCESS being a response code and not just 
a capability, perhaps the doc should explicitly call out that it can be 
used in tagged OR untagged responses.


> On 3/4/24 5:07 PM, Ken Murchison wrote:
>>
>> Sorry to keep replying to myself.
>>
>> It appears to me that the JMAPACCESS capability is useless unless its 
>> advertised pre-authentication, correct?  Otherwise, the client could 
>> receive a JMAPACCESS response code prior to knowing that it should 
>> expect one.
>>
>>
>> On 3/4/24 5:00 PM, Ken Murchison wrote:
>>>
>>> Oh, and a third point:
>>>
>>>   * The IANA section needs to register the JMAPACCESS capability.
>>>
>>>
>>> On 3/4/24 4:46 PM, Ken Murchison wrote:
>>>>
>>>> I gave this another read as I get ready to add support to Cyrus.  
>>>> Two comments:
>>>>
>>>>   * The DEBUGGING response code was removed from this spec, so I
>>>>     think the second paragraph of the introduction should also be
>>>>     removed.
>>>>   * The ABNF for the JMAPACCESS response code simply uses the
>>>>     'quoted' token where the JMAP Session URL is located.  I wonder
>>>>     if we need at least a comment that states that this should be
>>>>     the URL for JMAP Session resource, or maybe even go one step
>>>>     further and define it something like:
>>>>
>>>>     resp-code-jmapaccess    = "JMAPACCESS" SP jmap-session-url
>>>>
>>>>     jmap-session-url        = QUOTE https-URI DQUOTE
>>>>                                   ; https-URI defined in RFC 9110, 
>>>> Section 2.7.2
>>>>
>>>>
>>>> On 3/1/24 5:57 PM, The IESG wrote:
>>>>> The IESG has approved the following document:
>>>>> - 'The JMAPACCESS Extension for IMAP'
>>>>>    (draft-ietf-extra-jmapaccess-08.txt) as Proposed Standard
>>>>>
>>>>> This document is the product of the Email mailstore and eXtensions To Revise
>>>>> or Amend Working Group.
>>>>>
>>>>> The IESG contact persons are Murray Kucherawy and Francesca Palombini.
>>>>>
>>>>> A URL of this Internet-Draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-jmapaccess/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Technical Summary
>>>>>
>>>>>     This document defines an IMAP extension to let clients know that the
>>>>>     messages in this IMAP server are also available via JMAP, and how.
>>>>>     It is intended for clients that want to migrate gradually to JMAP.
>>>>>
>>>>> Working Group Summary
>>>>>
>>>>>     This is a short document with WG consensus to proceed.
>>>>>     Nothing was weird or controversial.
>>>>>
>>>>> Document Quality
>>>>>
>>>>>     There are no known implementations but multiple participants
>>>>>     have expressed intent to implement.
>>>>>
>>>>>     No special reviews were received or were required as a result
>>>>>     of Last Call.
>>>>>
>>>>> Personnel
>>>>>
>>>>>     The Document Shepherd for this document is Jiankang Yao. The Responsible
>>>>>     Area Director is Murray Kucherawy.
>>>>>
>>> -- 
>>> Kenneth Murchison
>>> Senior Software Developer
>>> Fastmail US LLC
>> -- 
>> Kenneth Murchison
>> Senior Software Developer
>> Fastmail US LLC
>>
>> _______________________________________________
>> Extra mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/extra
> -- 
> Kenneth Murchison
> Senior Software Developer
> Fastmail US LLC