Fair enough. :)<br><br><div><span class="gmail_quote">On 6/28/05, <b class="gmail_sendername">Brad Fitzpatrick</b> <<a href="mailto:brad@danga.com">brad@danga.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mostly not a problem. We could debate it for months but in the end people<br>would still only use HTML.<br><br>If anybody besides a few uber dorks start using non-HTML identity URLs,<br>then we can figure out the best for those sites to declare their OpenID
<br>server. Oh, but by then there will be a large installed base of OpenID<br>consumers that won't understand! (shock) So those early adopters will<br>have to wait it out, as they're good at anyway.<br><br>This is also why Net::OpenID::Consumer is bound to http and doesn't even
<br>accept https (would be a one character fix to change). I know there are<br>enough consumers out that that won't do/want to do https, so let's just be<br>realistic and say OpenID works for http and html.<br><br>Neighborhood pessimist,
<br>Brad<br><br>On Tue, 28 Jun 2005, M. David Peterson wrote:<br><br>> So is this a problem left unsolved or is it seen as simply not a problem?<br>><br>> On 6/28/05, Brad Fitzpatrick <<a href="mailto:brad@danga.com">
brad@danga.com</a>> wrote:<br>> ><br>> > We'd previously discussed a "magic" like that (cookies.txt, favicon.ico,<br>> > etc) but decided against it.<br>> ><br>> > Plus we're not going to let the OpenID core creep into public profile
<br>> > exchange. Private profile data might be an extension, outside the<br>> > core. But public stuff, absolutely not.<br>> ><br>> > - Brad<br>> ><br>> > On Tue, 28 Jun 2005, M. David Peterson wrote:
<br>> ><br>> > > To help maybe answer my own question is there any reason why, if the<br>> > link<br>> > > tag is not found as previously defined to then check the same directory<br>> > > specified for an
openid.xml file which would be a minimal atom feed such<br>> > as:<br>> > ><br>> > > <?xml version="1.0" encoding="utf-8"?><br>> > > <feed version="0.3" xmlns="
<a href="http://purl.org/atom/ns#">http://purl.org/atom/ns#</a>" xmlns:dc="<br>> > > <a href="http://purl.org/dc/elements/1.1/"">http://purl.org/dc/elements/1.1/"</a><br>> > > xml:lang="en">
<br>> > > <title><![CDATA[<XSLT:Blog />]]></title><br>> > > <link rel="openid.server" href="<a href="http://xsltblog.com/openid-server.app"/">http://xsltblog.com/openid-server.app"/
</a>><br>> > > <modified>2005-06-28T08:38:04Z</modified><br>> > > <tagline>An ongoing weblog of current topics from the XSLT development<br>> > > community &amp; other<br>
> > > XML/XSLT related news items. Hosted, maintained, &amp; edited by M.<br>> > David<br>> > > Peterson.</tagline><br>> > > <id>tag:<a href="http://www.xsltblog.com">www.xsltblog.com
</a> <<a href="http://www.xsltblog.com">http://www.xsltblog.com</a>> <<br>> > <a href="http://www.xsltblog.com">http://www.xsltblog.com</a>>,2005://1</id><br>> > > <generator url="
<a href="http://www.xameleon.org/">http://www.xameleon.org/</a>" version="0.1<br>> > ">Xameleon</generator><br>> > > <copyright>Copyright (c) 2005, m.david</copyright><br>
> > > </feed><br>> > ><br>> > > This would allow for the existing spec to work as is with the added<br>> > > insurance policy to allow a request for a specific atom xml file to<br>
> > override<br>> > > any potential web server issues that serve up other page formats based<br>> > on<br>> > > the client.<br>> > ><br>> > > This would also add bits of other information pertaining who the user
<br>> > is,<br>> > > etc... possibly for a richer user experience but thats obviously beyond<br>> > the<br>> > > scope of OpenID but within the scope of standards compliance which will<br>> > > allow for such information to be more easily consumed at the visiting
<br>> > site.<br>> > ><br>> > > Thoughts?<br>> > ><br>> > > On 6/28/05, M. David Peterson <<a href="mailto:xmlhacker@gmail.com">xmlhacker@gmail.com</a>> wrote:<br>> > > >
<br>> > > > Oooh... that is definitely something that should be reopened and<br>> > evaluated<br>> > > > to determine a solution that covers not only HTML/XHTML but, as<br>> > mentioned,
<br>> > > > common data feed formats + SVG, XUL, XAML, and/or any other XML format<br>> > which<br>> > > > in quite a short space of time will be seen more and more as the<br>> > default
<br>> > > > markup (and as such, namespace) for a variety of "pages" served up by<br>> > > > default when a particular framework (e.g. XAML) is known to be<br>> > available<br>> > > > on the client. In fact when you download and install the latest
<br>> > > > Indigo/Avalon WinFX beta release you are given the option to set IIS<br>> > 6.0to render the XAML version of a particular page when the client is<br>> > capable<br>> > > > and the server contains the proper xaml page in the directory
<br>> > requested by<br>> > > > this client.<br>> > > ><br>> > > > I realize that the page that is contained at the specified location<br>> > does<br>> > > > little more than act as a way to locate the proper validation
<br>> > information<br>> > > > and as such can be HTML/XHTML without effecting the rest of the<br>> > applications<br>> > > > contained on that particular server. But there are enough justifiable
<br>> > > > reasons (technical and marketing) for a web server to be allowed to<br>> > only<br>> > > > serve, for example, RSS and Atom data feeds, that I believe this will<br>> > become
<br>> > > > fairly common place in a fairly short period of time. In fact services<br>> > like<br>> > > > FeedBurner already allow the ability to host and serve up your data<br>> > feeds
<br>> > > > and as such the requirement to actually have a public site doesnt<br>> > exist,<br>> > > > instead using a simple tool to create and post your entries directly<br>> > to<br>
> > > > FeedBurner for publication.<br>> > > ><br>> > > > What then?<br>> > > ><br>> > > > On 6/28/05, Brad Fitzpatrick <<a href="mailto:brad@danga.com">brad@danga.com
</a>> wrote:<br>> > > > ><br>> > > > ><br>> > > > > On Tue, 28 Jun 2005, Mario Salzer wrote:<br>> > > > ><br>> > > > > > If now HTML/XML parsers check for the presence of <html>,</head>
<br>> > > > > > or <body> tags before actually reading out the two <link> tags,<br>> > > > > > they deprive themselves from supporting any other XML formats<br>> > > > > > which were especially designed with 'html compatibility' in mind.
<br>> > > > ><br>> > > > > The reason the head checks were done in Net::OpenID::Consumer was to<br>> > > > > prevent people from hi-jacking other people's webpages by leaving<br>
> > > > > comments/posts (which their software didn't strip) containing link<br>> > tags.<br>> > > > ><br>> > > > > But even a regular expression to search for any link tag after we
<br>> > > > > ascertain that the document isn't HTML (say, no <html> or <body> or<br>> > > > > <head>), that's still kinda lame. I suppose workable, though, if the<br>> > > > > regexp allows a namespace... but I'd in that case prefer a full-on
<br>> > XML<br>> > > > > parser so we can match on the /correct/ namespace.<br>> > > > ><br>> > > > > In practice, though, I imagine OpenID will be tied to HTML/XHTML,<br>
> > and I<br>> > > > > think that'll be fine.<br>> > > > ><br>> > > > > If you have a proposal though that doesn't add tons of complexity<br>> > for a<br>> > > > > couple geeks doing XML+XSLT to make their homepage, I'm all ears.
<br>> > > > ><br>> > > > > - Brad<br>> > > > ><br>> > > ><br>> > > ><br>> > > ><br>> > > > --<br>> > > > <M:D/>
<br>> > > ><br>> > > > M. David Peterson<br>> > > > [ <a href="http://www.xsltblog.com/">http://www.xsltblog.com/</a> ][ <a href="http://www.xmlblogs.net">http://www.xmlblogs.net</a> ]<br>
> > ><br>> > ><br>> > ><br>> > ><br>> > > --<br>> > > <M:D/><br>> > ><br>> > > M. David Peterson<br>> > > [ <a href="http://www.xsltblog.com/">
http://www.xsltblog.com/</a> ][ <a href="http://www.xmlblogs.net">http://www.xmlblogs.net</a> ]<br>> > ><br>> ><br>><br>><br>><br>> --<br>> <M:D/><br>><br>> M. David Peterson<br>> [
<a href="http://www.xsltblog.com/">http://www.xsltblog.com/</a> ][ <a href="http://www.xmlblogs.net">http://www.xmlblogs.net</a> ]<br>><br></blockquote></div><br><br><br>-- <br><M:D/><br><br>M. David Peterson<br>
[ <a href="http://www.xsltblog.com/">http://www.xsltblog.com/</a> ][ <a href="http://www.xmlblogs.net">http://www.xmlblogs.net</a> ]