Hi, >>>> 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.
Fair enough. I do agree that, in other protocols, defining new error codes etc do now always mean updating of specs. --- >>>> 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? I was thinking of e.g., a note that highlights the issue. But, I do agree it should be obvious to people familiar with the specs, so if you don't think it is needed I will not argue against you :) I assume there will be no indicator in the initial request informing the server whether the client supports the feature or not? ---- 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. Thanks! Regards, Christer
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
