[Openstandaarden] Instant messaging - jullie gedacht?

[Mark Van den Borre]

Op do 16-10-2003, om 13:03 schreef Herman Bruyninckx:
> > A more healthy situation for the IM world would be like:
> > 
> > Companies X, Y and Z provide instant messaging services.
> > * X, Y and Z must fully disclose all their messaging specs.
> Waarom moeten alle bedrijfs-initiatieven verplicht geopend worden? Zij
> mogen m.i. kiezen wat ze doen, 
Het gaat hier voor alle duidelijkheid over doordeweeks instant
messaging-gebruik tussen individuele gebruikers, genre Yahoo, AIM, MSN.
Over de rest heb ik nog niet echt nagedacht.
Je voelt toch met de ellebogen dat er iets mis is als je niet kan
communiceren met 30 van je nauwste online-contacten omdat firma X
kunstmatig de toegang tot haar netwerkinfrastructuur beperkt op basis
van de gebruikte client. Zelfs al wil je voor hun dienst betalen, je kan
niet.

> en het is slechts als een bepaalde
> dienst officieel voor overheidsdoeleinden gebruikt wordt dat er een
> probleem kan rijzen. MSN is voor zover ik weet een prive-initiatief,
> en dus is regulatie niet gepast. Dit soort "eisen" geeft ons een
> slecht, anti-bedrijfs imago..
Dit was een strikt individueel bericht op een discussieforum, zonder nog maar de naam openstandaarden.be te noemen.
Het was zelfs geen vaststaand standpunt, maar eerder een proefballonnetje. Dank dus voor je reactie.
Regulatie hoeft helemaal niet anti-corporate te zijn. Voor zover
oligopolies synoniem voor corporate zijn wel, natuurlijk...

> > * The user must be able to export all of his/her user information
> > (contacts!) from the company X, Y or Z network painlessly.
> De gebruiker moet maar aanbieders kiezen die hem deze optie geven.
> In de huidige praktijk is het monopolie van MS natuurlijk een heel
> grote drempel, maar _principieel_ moet "de markt" maar beslissen.
> 
> > * X, Y and Z can't offer any messaging clients themselves (no messing
> > with specs, guaranteed).
> Dit gaat _veel_ te ver! Als ze _geen_ clients zouden aanbieden zou de
> reactie begrijpelijkewijze erg negatief zijn: "Kijk, ze willen een
> dienst verkopen, maar ze helpen ons niet om die dienst te
> gebruiken..."
De netwerken kunnen wel grants geven voor het ontwikkelen van clients.
Ze kunnen ook gewoon wachten op implementaties.
Het is enkel een (overdreven paranoïde?) manier om de markt niet te
stremmen door een vieze mix tussen netwerk en voorkeursclients toe te
laten.

> > ? X, Y and Z aren't allowed to check what messaging client is being
> > used. Just to make sure they don't discriminate based upon that.
> Akkoord met het laatste, niet met het eerste!
Alweer, het klinkt paranoïde, maar een rigoureuze scheiding tussen client en netwerk geeft betere kans op correct functioneren van "de markt".
Althans, dat vermoed ik.
En over eventuele veiligheidsrisico's... Moeten die niet opgelost worden
aan de protocolkant, en door de vraag van de markt?

> > * X, Y and Z can charge every user a uniform, transparent access fee,
> > flat or usage based. No fee discrimination based upon client platform.
> Dat is hun probleem... (Zie mijn opmerking over "de markt".)
Hier ging ik zeker te ver. Zolang de fee niet discrimineert op basis van
client en ergens in verhouding staat tot de kostprijs is er geen
probleem. Vergelijk het met interconnectie-tarieven in de
telefoonwereld...

> Ik denk dat we _tegen_ monopolies moeten ijveren, maar niet _voor_
> regulering...
Mijns inziens is dat in innerlijke tegenspraak. Merk op dat ik niet met
ideetjes voor _technische_ regulering speel. Het blijft in dit scenario
nog steeds mogelijk onbelemmerd technisch innovatief te zijn op gebied
van specs zowel als clients.

Het enige waar ik aan dacht was het reguleren van wat een gigantisch en
groeiend probleem is, de lock-in.

Mark
-- 
Mark Van den Borre
Noormannenstraat 113
3000 Leuven, Belgium
+32 486 961726
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dit berichtdeel is digitaal gesigneerd
Url : http://www.openstandaarden.be/pipermail/openstandaarden/attachments/20031016/2858b230/attachment.pgp