decoupling from HTML

Brad Fitzpatrick brad at danga.com
Tue Jun 28 11:49:58 PDT 2005


Mostly not a problem.  We could debate it for months but in the end people
would still only use HTML.

If anybody besides a few uber dorks start using non-HTML identity URLs,
then we can figure out the best for those sites to declare their OpenID
server.  Oh, but by then there will be a large installed base of OpenID
consumers that won't understand!  (shock)  So those early adopters will
have to wait it out, as they're good at anyway.

This is also why Net::OpenID::Consumer is bound to http and doesn't even
accept https (would be a one character fix to change).  I know there are
enough consumers out that that won't do/want to do https, so let's just be
realistic and say OpenID works for http and html.

Neighborhood pessimist,
Brad

On Tue, 28 Jun 2005, M. David Peterson wrote:

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


More information about the yadis mailing list