Thanks Christer and Vittorio, I've snipped out some unneeded parts of the prior conversation and added my replies to parts inline below.
On Tue, Feb 28, 2023 at 5:09 AM Christer Holmberg < christer.holmb...@ericsson.com> wrote: > > >> QMa1: General > >> > >> As the document defines a new error code, and define new > >> WWW-Authenticate > >> parameters, should the document not be an Update to RFC 6750? > > > > It's a good point to consider. Our rationale is that this document > leverages > > many different extension points baked in a number of existing specs, > hence > > it doesn't seem a slam dunk to determine which one we should "inherit" > from. > > Since the draft refers to RFC 6750 I would assume that is the spec at > least > being updated. > > But, if the draft also updates procedures etc of other specs I guess those > may > also be updated. I don't have the expertise to have an opinion on whether > that > is the case. > The thrust there wasn't to suggest that this draft needs to update other specs. Rather to say that this draft utilizes defined extension points provided by a number of RFCs (like RFC6749, RFC6750, RFC7662, RFC7519) and the associated registries where appropriate/needed. Those extension points have been used by other specs already without the spec doing the extension formally updating the RFC that it's using the extension points of. More generally, our rationale and attempt to follow precedent here was that the utilization of defined extension points didn't warrant "Updates" to the specs providing those extension points. > >> QMa2: Section 4 > >> > >> The text defines the procedures for the client. > >> > >> But, what if the client does not support the new error code and the > new > >> WWW-A parameters? I think there should be some backward > compatibility > >> text > >> (or reference, if defined elsewhere). > >> > >> Especially it should be clear that the server will not receive the > WWW-A > >> parameters in the new request if the client does not support them. > > > > This is a tricky one. Technically, every extension starts its existence > with > > zero support from existing clients. > > Yes, and I have been in many situations where people argue on what is the > correct behavior when one endpoint supports an extension, the other > doesn't, > and there are no defined backward compatibility procedures to refer to :) > > > Implementers should be familiar with this, and specs stipulate that any > > entity receiving a parameter it doesn't understand to ignore that > parameter, > > from which it follows that whatever semantic or directive that parameter > > carries will remain not executed. > > Saying in the document that clients not supporting the parameters we are > > defining here will not achieve the goals of the spec seem somewhat > > redundant. What do you think? > > I think it is more than just "not achieving the goals". Clients that do > not > support the extension may end up not getting any service at all, as they > don't > understand that the reason for rejection is not meeting the authentication > requirements. > Yes, clients that do not support the extension will not understand the new error code and auth-params and won't know to act accordingly. That is the nature of these kinds of extension points. This draft can't change how the underlying specs expose extensions (and I honestly wouldn't know how to do it differently even if it could). Of course, existing software that is unaware of this draft can't have any behavior dictated by this draft. For the case where an entity doesn't support the extension, I don't see how this document could say anything meaningful about compatibility. Other than to remark or reiterate that an entity that doesn't understand the extension will not understand it, which seems neither actionable nor useful in the document. Honestly, what language would we even use here? > ---- > > Minor issues: > > QMi1: Section 3 > > >> Can the new WWW-Authenticate parameters only be used with the new > error > >> code? If so, please indicate it. > > There doesn't seem to be any obvious reasons to ban future extensions > from > > using those parameters, nor there appear to be obvious scenarios where > we > > would proactively > > suggest doing so: that's our rationale for not having commented on this > > aspect in the document. > > One alternative would be to not ban, but to say that THIS spec only > defines > usage of the parameters with the new error code, but that future specs may > define usage with other error codes. > That seems like a worthwhile clarification to make. Thanks. We will add/adjust some text accordingly. -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
