<!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>I like the general idea you describe here.<BR>
<BR>
I'm just coming up to speed on the numerous identity ideas discussed<BR>
on the list, so bear with me, but one thing intrigues me: the reliance of<BR>
underlying HTML. The protocol is defined as HTTP URLs. Why depend<BR>
on HTML parsing abilities? We could rely on HTTP header fields to carry<BR>
info.<BR>
<BR>
Martin's use of the Accept header is a good showcase for how to remove<BR>
the requirement of HTML parsing. The capabilities formats discussed<BR>
are expressable in an HTTP header. If existing HTTP1.1 headers are not<BR>
enough, 'x-' style headers can be used. Makes any sense?<BR>
<BR>
Similarly, can we not use HTTP redirects instead of putting delegation<BR>
information in &lt;HEAD&gt;?<BR>
<BR>
Secondly, about the capability description document: It seems risky to<BR>
have identity leaking through (a username can tell a lot&nbsp; -- and quite a<BR>
few people base passwords on the username too). I think there is a real<BR>
risk here.<BR>
<BR>
Thanks,<BR>
Hans<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>