[http-state] Question regarding RFC 6265 and ietf process

[Fagner Martins <[e-mail]>]

Hi.

Sorry to bother but I really have no idea who to ask about this and I hope
I came to the correct mailing list.

A few weeks ago I did implemented a JavaScript library to handle
client-side cookies using the RFC 6265 as a baseline to percent-encode only
the cookie characters that are not allowed in the RFC, see
https://github.com/js-cookie/js-cookie/tree/f28a0fdfc0f780406a4f083c1ec410c77acf55ec#encoding
.

The thing is that recently we found out that some frameworks and
server-side programming languages, for historical reasons, do not accept a
character that the RFC allows. Here an example of the "+" octet:
https://github.com/js-cookie/js-cookie/issues/70#issuecomment-126965203

Unfortunately those languages and frameworks cannot change the way they
handle cookies because in most of them the default cookie mechanism is
built-in very hard into the internals of the language/framework, and even
if they could, it would take time for the implementation reach to the
developers hand.

I am not a veteran on the internet, so I am not aware of how the process
works. But would it make sense to amend the RFC to account for characters
allowed in the browsers but realistically disallowed by most frameworks due
to historical reasons?

It would be very useful to make the RFC a documentation to serve as a
baseline for how the web *and the server-side languages *that are built on
it actually work instead of restricting only to how browsers work in the
wild.

Does it makes sense?

Thanks!
----------------------------------------------------
Fagner Martins Brack
http://www.fagnerbrack.com/
https://github.com/FagnerMartinsBrack?tab=activity
http://stackoverflow.com/users/1400037/fagner-brack
http://br.linkedin.com/pub/fagner-martins-brack/69/48/719