-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why ABNF for WIT? #32
Comments
The last time I went through the process of requesting registration of an HTTP Field Name to carry a JWT, there was some grumbling from one of the designated experts about it not being defined as an RFC 8941 Structured Field Value. When it was explained that there wasn't really an appropriate SF type to carry a JWT (and especially that sf-binary didn't fit at all) the grumbling shifted to general complaints that the syntax wasn't well defined (despite, as you point out, the syntax of a JWT being completely defined by JWT). The grumbling was partially mollified by the addition of some less than useful ABNF (found here). It was more involved than that, of course, but that's the basic story line. So I thought I'd try and get ahead of that kind of DE push-back a bit while adding some ABNF that's a little more descriptive/useful. Which is what is here. I think the WPT header field should also get some ABNF but I couldn't fit it in as well and ran out of time for the pre -00 PR deadline. |
@bc-pi: we should have a similar (same?) ABNF for the WPT. |
In Sec. The WIT HTTP Header, we define the ABNF even though we say the WIT is a JWT and this completely defines the syntax. IMO the ABNF could actually confuse implementers.
The text was updated successfully, but these errors were encountered: