Just thinking about how I would document this, and I realized that IETF documents switched to talking about "octets" long ago. When an RFC says "characters" it almost always means orthographic characters in some encoding that may not map 1-1 from characters - octets.
Proposal for current docs =~ s/bytes/octets/g Aaron On Thu, 2007-12-20 at 08:53 -0800, Dustin Sallings wrote: > > > Understood. The same problem you mentioned (inconsistent encoding > by not specifying a charset) applies to the key as well. > > > The problem that prompted this question, though is a bug where I > assume the length of the string is the same as the number of bytes > that will be in it on the wire. I'd always assumed keys to be ascii, > so that's true for all my use cases, but it's not true in general. > > > I asked this question to know whether to consider multibyte > characters an error or a valid use case. Sounds like it's valid, so > I'll make it work. > > -- > Dustin Sallings (mobile) > > On Dec 20, 2007, at 8:42, "Rakesh Rajan" <[EMAIL PROTECTED]> wrote: > > > > > Dustin, just to clarify the bug report that I emailed you, the > > problem was with the "value" and not the "key". > > > > Since you bought up the key issue with UTF8, I think that it is > > acceptable to force users to use ASCII as key, but allow values to > > be UTF8. > > > > -Rakesh > > > > > > > > On Dec 20, 2007 9:15 AM, Steven Grimm <[EMAIL PROTECTED]> wrote: > > On Dec 19, 2007, at 7:43 PM, Dustin Sallings wrote: > > >> For the binary protocol I think none of this should > > matter at all. > > >> A key has a key length, so the question of valid > > characters should > > >> not be relevant. > > > > > > That's true, but it'd be really nice to not have > > different rules > > > based on protocol. > > > > > > In particular, I think it's unacceptable to be able to set a > > key/value > > pair with the binary protocol that you can't retrieve with > > the text > > protocol. > > > > -Steve > > > >
