Een ampersand als kunstgreep

ampersand.pngRechters hebben niet altijd verstand van techniek, maar ze weten heel goed wanneer iemand bijdehand staat te doen. Zo ook het Europese Hof van Justitie, dat in zaak C-569/08 een .eu-domeinnaamclaim afwijst omdat de aanvrager te kwader trouw heeft gehandeld. Die had, kort gezegd, beschrijvende woorden gedeponeerd als merk met een ampersand tussen elke letter. Met een merk zou hij voorrang krijgen bij de uitgifte van .eu domeinnamen, en zo zou hij dan de beschrijvende domeinnamen kunnen inpikken.

Bij de uitgifte van .eu domeinnamen werd gewerkt met een zogeheten ‘sunrise’, waarbij merkhouders voorrang kregen op het gewone volk dat graag een .eu domeinnaam wilde hebben. Echter, je mocht dan alleen domeinnamen aanvragen die overeenstemden met je merk. Een zuiver beschrijvende naam, bv. “banden” voor een bedrijf dat in banden handelt, kon tijdens de sunrise niet worden aangevraagd.

Het bedrijf Internetportal zag echter mogelijkheden: ze deponeerden een Zweeds merk voor &R&E&I&F&E&N& en claimden vervolgens de domeinnaam reifen.eu. In het DNS is het namelijk niet mogelijk om ampersands in domeinnamen te hanteren, zodat die worden weggelaten bij het bepalen welke domeinnaam je mag krijgen als merkhouder. En dat gaf hier het leuke resultaat dat men nu de domeinnaam voor het beschrijvende woord “Banden” in het ZweedsDuits te pakken had.

Een Benelux-merkhouder maakte bezwaar tegen deze toekenning. Zij wilde zelf deze domeinnaam hebben, op grond van haar merkrecht Reifen voor raamreinigers. En die zaak ging tot aan het Europese Hof, dat oordeelde dat hier sprake was van een merkregistratie te kwader trouw. Het Hof noemt het een kunstgreep om een merk te registreren met “het oogmerk om het merk niet te gebruiken op de markt waarvoor de bescherming is aangevraagd”, zeker als je dat doet voor een groot aantal (180!) met soortnamen overeenstemmende merken tegelijk en ook nog eens kort vóór het begin van de registratie van .eu-topleveldomeinnamen.

Oftewel: leuk geprobeerd maar geen sigaar. En geen domeinnaam.

Arnoud

16 reacties

  1. Over ampersands gesproken, ik heb niet zo lang geleden nog een email naar ICTRecht.nl gestuurd. Daarin heb ik uitvoerig uitgelegd hoe misplaatste ampersands in de RSS web feed van die site leiden tot een corrupt XML bestand, met als gevolg dat feed readers er niets mee kunnen. Tot op heden nog geen reactie gehad en het probleem lijkt nog steeds niet te zijn opgelost.

    Misschien niet alleen rechters die niet altijd verstand hebben van de techniek 😉

    (geen kritiek overigens; hooguit een kwinkslag. Ik heb het probleem voor mezelf reeds opgelost)

    Keep up the good work en de groeten.

  2. Ik vraag me af wat het nut was van &R&E&I&F&E&N&, anders dan het claimen van Reifen.eu opzich dus een goed oordeel!

    zo zie je maar dat digibeten ook zinnige oordelen kunnen vellen. (niet dat ik de betreffende rechter een digibeet vindt, maar het lijkt eerder regel dan uitzondering)

  3. Maar heeft hij nou wel nog 180 merken op zijn naam staan? Hij heeft dan namelijk de domeinnamen niet kunnen registreren maar heeft natuurlijk wel nog al die &o&n&z&i&n&-merken op zijn naam staan…

    Ook grappig: Google Translate vertaalt “reifen” naar “volwassen”. (“Mature” in engels maar dan krijg je er nog een verzameling andere betekenissen bij…)

  4. @Elwin: die mail heb ik nooit gezien. Het probleem zit hem in de syndicatie van Security.nl, daar zit de ampersand niet goed. Hoe heb jij het opgelost?

    @Wim: ja op zich wel, hoewel hij die registraties nu natuurlijk beter kan opzeggen. Dit oordeel betreft formeel alleen dit ene merk, maar bij elk ander merk van deze soort gaat het zonder meer op lijkt me.

  5. @6, de feed van Security.nl is inderdaad fout, maar hij zou niet mogen crashen bij het parsen:

    <item> <title>AT&amp;T geeft hackers schuld van iPad-lek</title> <!-- goed: enkelvoudig escapen --> <description>Het uitlekken van 114.000 e-mailadressen van iPad-eigenaren is de schuld van een stel kwaadaardige hackers, zo heeft AT&amp;T in een brief aan klanten laten weten.</description> <!-- fout: enkelvoudig escapen toegepast waar dubbel escapen moet --> </item>

    De description in RSS moet namelijk eerst ‘normaal’ uitgelezen worden, zoals elk ander XML-element, en het resultaat daarvan (‘Het uitlekken van 114.000 e-mailadressen van iPad-eigenaren is de schuld van een stel kwaadaardige hackers, zo heeft AT&T in een brief aan klanten laten weten.‘) moet door een HTML-parser gehaald worden, die geen fout moet geven. De HTML-parser zou er weer & van moeten maken bij gebrek aan de naam van een entiteit na de ampersand. Echter in de feed had ‘&amp;amp;‘ moeten staan. In de itemtitel dan weer niet, want de itemtitel bevat platte tekst i.p.v. HTML.

    Zie hier de escape-chaos waarom Atom in het leven is geroepen als vervanger voor RSS. Concrete oplossing voor nu: vraag Security.nl om een Atom-feed en/of wijs ze op het RSS Best Practices Profile dat bovenstaande definieert. 🙂

  6. @Blijbol, het is gewoon XML dus een enkelvoudige escape zou voldoende moeten zijn. Hoewel… De ‘description’ zou eigenlijk geen HTML mogen bevatten maar sommigen vinden het practisch om toch HTML codes in dit veld op te nemen. En ja, sommige feedreaders willen dan een dubbele parsing uitvoeren. En dat gaat dus niet volgens de standaard. Of, eigenlijk schrijft de standaard hier niets over voor, behalve dan dat alles conform de XML 1.0 standaard moet kloppen. De feed is dus conform specificaties, alleen de feedreader zoekt er meer achter

    Het is wel een mooi voorbeeld waarom software vaak de mist in gaat: onduidelijkheden over standaarden en specificaties. 🙂

  7. @Wim: het staat inderdaad niet in de RSS-specificatie maar wel in het later verschenen Best Practices Profile:

    “For all elements defined in the RSS specification that enclose character data, the text SHOULD be interpreted as plain text with the exception of an item’s description element, which MUST be suitable for presentation as HTML.” Bron: http://www.rssboard.org/rss-profile#data-types-characterdata

    In Atom is het leven makkelijker, dan doe je gewoon wel of geen type=”html” op het element.

  8. @Blijbol… Tja. De RSS standaard is nu eenmaal opgezet door het Berkman Center for Internet & Society at Harvard Law School en vrijgegeven als CC-BY-SA. De RSS Advisory Board heeft hier dus op voortgebouwd, waar op zich niets mee mis is. Het betekent echter wel dat we kunnen kiezen tussen welke standaard we willen gebruiken, namelijk de Harvard versie of de RSSAB versie. Mijn visie op dit probleem is dat RSSAB op een verkeerde manier varianten probeert te implementeren. Het is vrij eenvoudig om een extra namespave te introduceren die RSS readers kunnen begrijpen en waaraan ze kunnen herkennen dat het een RSSAB formaat betreft. Oude feedreaders negeren deze namespace gewoon en nieuwe feedreaders kunnen hier rekening mee houden.

  9. @arnoud: ik heb op verschillende manieren geprobeerd de oplossing voor het probleem hier te posten, maar werd keer op keer door de firewall van deze site (ten onrechte) tegen gehouden (false positives). Ik heb de oplossing daarom maar even via email verstuurd. Wie weet kun jij het hier publiceren indien je denkt dat anderen er ook iets aan zouden kunnen hebben.

    De groeten.

  10. @Blijbol: Het door jouw geleverde voorbeeld van Security.nl is niet het probleem. De &amp; referenties zijn volgens mij voor de xml validatie gewoon toegestaan. De verchillende readers die ik getest heb heben er in ieder geval geen probleem mee.

    Het werkelijke probleem (tijdens het parsen van de xml) zijn de urls waarin ampersands zitten die niet ge-escaped zijn. Geen RSS probleem maar een XML validatie probleem.

  11. @Wim: er is geen keuze tussen die twee: de een zegt gewoon niets en de ander zegt dubbel escapen, dus alle standaarden die iets zeggen over escapen, zeggen dat het dubbel moet.

    Gelukkig is die nieuwe naamruimte er dus al: Atom. 🙂

    @Elwin: dat zou kunnen. Zoals ik al aangaf, zou het ook moeten werken, tenzij een onvergeeflijke HTML-parser kan roet in het eten zou gooien. Blijft staan dat de feed niet correct is.

  12. Er zaten nog wel meer kunst grepen bij die EU registratie. Zo mocht je naast het weglaten van de & hem ook vertalen naar “en”, “and”, “und”, etc.. Er zijn een boel creatievelingen geweest tijdens die sunrise 😉

    De lachende derde waren waarschijnlijk al die merknaam instanties.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.