<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7232.11">
<TITLE>RE: YADIS as an abstraction layer</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>> Most human-readable things on the web are HTML. People are familiar with<BR>
> HTML. There are lots of people that can write HTML but don't even know<BR>
> what HTTP headers are, let alone how to change them.<BR>
> . . .<BR>
> Sure, it's not ideal from a technological perspective, but<BR>
> pie-in-the-sky pure implementations that don't pay any mind to current<BR>
> realities rarely get very far.<BR>
<BR>
Oh, I agree with this. Most of it.<BR>
<BR>
The reliance on HTML should be made explicit somehow . . . People don't<BR>
break protocols. Implicit dependencies break protocols. ;)<BR>
<BR>
Perhaps: the requested format of the response is part of the request, a la<BR>
"format=xyz" param/value, where HTML is the default value, or similar.<BR>
<BR>
>> Secondly, about the capability description document: It seems risky to<BR>
>> have identity leaking through (a username can tell a lot -- and quite a<BR>
>> few people base passwords on the username too). I think there is a real<BR>
>> risk here.<BR>
><BR>
><BR>
>This is an intreiguing observation. I'm a little taken aback by it since<BR>
>people share usernames all the time. Do you have a solution in mind?<BR>
<BR>
Not as such. I just happened to see plaintext usernames in the response<BR>
and thought about the old "i_hate_xyz" username problem.<BR>
<BR>
I'll have to think further what it all means.<BR>
<BR>
Hans</FONT>
</P>
</BODY>
</HTML>