[db-wg] Deal with "non-breaking-space"-characters in updates
- Previous message (by thread): [db-wg] Deal with "non-breaking-space"-characters in updates
- Next message (by thread): [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber
Woeber at CC.UniVie.ac.at
Thu Jul 9 11:33:31 CEST 2015
Ho Nick, Nick Hilliard wrote: > On 08/07/2015 17:18, Ruediger Volk, Deutsche Telekom Technik - FMED-41.. wrote: > >> > Summary: >> > Currently the whois database accepts =E2=80=9Cnon-breaking-space=E2=80=9D- >> > characters in updates. We propose that whois replaces these >> > =E2=80=9Cnon-breaking-space=E2=80=9D-characters with regular spaces >> > before storing the object. > > > I'm going to giggle a bit here. :-) > Wilfried, while I accept your point in principal, Ruediger's mime > formatting unintentionally demonstrates how easily nbsp can cause serious > breakage, and that there are many locations in an rpslng object which > should only accept a limited ASCII charset. Indeed, while reading Rüdiger's mail I relized that I wasn't thinking along the path that he was. I was more on the issue of "randomly" doing things to updates. > Blindly accepting utf8 everywhere is a bad idea. Right. I think the *everywhere* is the important thing here. > The viable options for > handling this are inbound fixup MAybe, but then at least a Warning should be returned. > or else rejection of malformed updates. My pov is that this option should be chosen. > Either is ok with me, but whichever choice is made needs to be documented > clearly. +1 > Nick Wilfried
- Previous message (by thread): [db-wg] Deal with "non-breaking-space"-characters in updates
- Next message (by thread): [db-wg] MD5s of the RIPE database, Deprecation of MD5 and safe authentication methods
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]