Re: [Last-Call] Secdir last call review of draft-ietf-extra-jmapaccess-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




-----Original Message-----
From: Arnt Gulbrandsen <arnt@xxxxxxxxxxxxxxxxxxx> 
Sent: October 19, 2023 9:58 AM
To: Daniel Migault via Datatracker <noreply@xxxxxxxx>
Cc: secdir@xxxxxxxx; draft-ietf-extra-jmapaccess.all@xxxxxxxx; extra@xxxxxxxx; last-call@xxxxxxxx; Daniel Migault <daniel.migault@xxxxxxxxxxxx>
Subject: Re: Secdir last call review of draft-ietf-extra-jmapaccess-04

Hi,

thanks for your review.

Daniel Migault via Datatracker writes:
> A complete equivalence may not be very clear. At least I think it 
> means that the messages are available in both format IMAP and JMAP, 
> but it could also be read as messages in IMAP and JMAP are fully 
> equivalent which is not the case necessarily as with 
> internationalization the JMAP and IMAP version may differ.

No, that kind of downgrading was deprecated before JMAP, when RFC 6530 etc. 
replaced 5738. At current, the message is available in the form in which it was received, and any downgrading happens at read time. If the IMAP client says "give me the to and cc fields" the response may be downgraded. But it remains available.

I've looked at the text and it seems as good as can be, I think.

<mglt>
I think "equivaence" confuses me, but I am fine if that is only me. For my information is-it what the text wants to say?

For  simplicity, we consider in this document  that all messages are available via both IMAP and JMAP.
</mglt>

>    By advertising the JMAPACCESS capability, the server asserts that if
>    a mailbox or message has a particular object ID when accessed via
>    either IMAP or JMAP (see [RFC3501], [RFC9051] and [RFC8620]), then
>    the same mailbox or message is accessible via the other protocol, and
>    it has the same ID.
> <mglt>
> The way I understand it is that JAMPACCESS can also be used by JMAP 
> client to advertise the existence of an IMAP version. If that is 
> correct the term JMAPACCESS may be a bit surprising.

Could you elaborate on that? It's a misunderstanding and I'd like to preclude it in the text.

JMAP clients don't advertise extensions. IMAP servers do.

<mglt>
I was missing that bit. Indicating that the server is IMAP not JMAP maybe helps  "By advertising the JMAPACCESS capability, the IMAP server asserts... "
</mglt>

> The way I see this is that DEBUGGING is being used to carry an 
> information that is not yet an error. It is just something informative. ...

I removed the entire DEBUGGING, it's not central to JMAPACCESS and was too much trouble.

<mglt>
ok
</mglt>
> What is the JMAP server has already been explained, and it seems 
> sufficiently obvious to not repeat it. This is just a nit.

Someone else wanted it, and the repetition is just a few words anyway.

<mglt>no big deal indeed.</mglt>
> Just to make sure I understand it correctly, I am expecting the client 
> to re-authenticate itself the same way as it does for IMAP to JMAP.

Yes.

> In other words, the IMAP authentication is not used to access the JAMP 
> resources.  If that were the case, one need to make sure that JMAP 
> resources are accessed via the same IMAP authenticated session - which 
> mau not be trivial. It might be simpler to have the JMAP and IMAP 
> doing their own authentication.
> I think this needs to be clarified.

What does it mean that "JMAP resources are accessed via the same IMAP authenticated session"?

The two each do their own authentication. What JMAPACCESS says is that based on the IMAP authentication performed by the client, it's clear that if the client has JMAP client capability, then it's also able authenticate via JMAP and will in that case have access to the same mail and mailboxes.

<mglt>

That is great and address my concern. I was afraid that the client authenticated to IMAP and that authentication being re-used for the JMAP access. That is not the case, but maybe you could clarify that. 
</mglt>

> What is not very clear to me is how authentication is performed on the 
> JMAP server.

Why should that be included in this document? This document says:

1. There exists a way to access the same mail via JMAP.
2. Based on the authentication process, the IMAP server can see that if the client were to connect via JMAP, then the credentials it just used via IMAP could be used to authenticate via JMAP.

I don't see any reason to specify anything about how the authentication may happen. If the server supports the same authentication method for both protocols, then fine, right? What's the argument for limitig that, excepting some methods, or adding other additional rules?

<mglt>
The credential used for the authentication and the authentication are two things. In my opinion it should be clearly mentioned that the JMAP server authenticates the client and that the IMAP authentication is not re-used. I agree you can re-use the same credentials. 
<mglt>

I'll upload -05 now.

Arnt
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux