Originally submitted by Justin Richer (Justin Richer) on 2022-12-02
From my review of CIBA as IANA designated expert:
Section 16.2 defines “backchannel_user_code_parameter”, with the description text of:
Indicates whether the Client must support the CIBA user_code parameter.
However, section 4, referenced from the registration, defines it as:
Boolean value specifying whether the Client supports the user_code parameter.
The discrepancy is that the text in 16 is a requirement (must support) with expectations that an AS could ostensibly count on (as in, the client will always use that parameter), whereas the text in 4 is a statement of capability (as in the client could use that parameter when it wants to).
This is likely a small change, but I’m not sure which direction the WG intends, so hopefully Mike can clarify. I personally think the language in 4 I likely the intended direction, so removing the “must” and fixing the grammar:
Indicates whether the Client supports the CIBA user_code parameter.
I don’t want to get into bike shedding, but I do think this is a good a time as any to point out that “backchannel_user_code_parameter” isn’t a great name for this field. As it stands, it sounds like it’s declaring the name of the parameter that will contain the user code, not a flag to turn a function on/off. It should probably be “backchannel_user_code_parameter_supported” or “backchannel_user_code_parameter_required”, to parallel other parameters in the registry from other specifications.
Bitbucket status: new
Bitbucket origin: issue 211
From my review of CIBA as IANA designated expert:
Section 16.2 defines “backchannel_user_code_parameter”, with the description text of:
However, section 4, referenced from the registration, defines it as:
The discrepancy is that the text in 16 is a requirement (must support) with expectations that an AS could ostensibly count on (as in, the client will always use that parameter), whereas the text in 4 is a statement of capability (as in the client could use that parameter when it wants to).
This is likely a small change, but I’m not sure which direction the WG intends, so hopefully Mike can clarify. I personally think the language in 4 I likely the intended direction, so removing the “must” and fixing the grammar:
I don’t want to get into bike shedding, but I do think this is a good a time as any to point out that “backchannel_user_code_parameter” isn’t a great name for this field. As it stands, it sounds like it’s declaring the name of the parameter that will contain the user code, not a flag to turn a function on/off. It should probably be “backchannel_user_code_parameter_supported” or “backchannel_user_code_parameter_required”, to parallel other parameters in the registry from other specifications.
Bitbucket status: new
Bitbucket origin: issue 211