From: Jim Dabell (jim-blogite@jimdabell.com)
Date: Sun Sep 08 2002 - 19:05:01 BST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 08 September 2002 4:08 pm, Ian Hickson wrote:
[snip]
> Anyway, I just finished editing 0.9.1. Please read the spec and comment
> here.
[snip]
Okay, well I've got a few proposals for additions and alterations, based on
the last version. The big thing is the addition of the generic XML
description file already discussed here. Some of it still needs to be
fleshed out of course, but I think this retains the simplicity of the
original method, keeps backwards-compatibility, while allowing for more
advanced usage.
I'd prefer the distinction to be made between the specification - the
description of the communication - and the mechanics of actually doing it.
I'd put the latter in an appendix.
By the way, I was unaware that <link> could also be specified as an HTTP
header. Does anybody have a link to more information? Is it really that
hard to parse?
Abstract:
[rewording & expansion]
Pingback is a method for web authors to request notification when
somebody links to one of their documents. Typically, web publishing
software will automatically inform the relevent parties on behalf of
the user, allowing for the possibility of automatically creating links
to referring documents.
For example, Alice writes an interesting article on her Web log.
Bob then reads this article and comments about it, linking back to
Alice's original post. Using pingback, Bob's software can
automatically notify Alice that her post has been linked to, and
Alice's software can then include this information on her site.
Introduction:
[rewording to remove focus on blogs and make things a little clearer]
The Pingback system is a way for a website to be automatically
notified when other websites link to it. It is entirely transparent to
the linking author, requiring no user intervention to
work, and operates on principles of automatic discovery of
everything that it needs to know. A sample blog post involving Pingback
might go like this:
- - Alice posts to her blog. The post she's made includes a link to a post on
Bob's blog.
- - Alice's blogging system sees the link, and contacts Bob's Pingback system
and says "look, Alice made a post which linked to one of your posts".
- - Bob's blogging system then includes a link back to Alice's post on the
original post.
- - Users can then follow this link back to Alice's post and read more.
It enables reverse linking - a way of going back up a chain of
links rather than merely drilling down.
Technical Details:
[Inclusion of Simple/Generic distinction]
The Pingback system uses HTML/XHTML <link> elements, and optional x-pingback
HTTP headers to indicate that a document is requesting notification of
linking. There are two levels of support for the Pingback system, Simple
Pingback, and Generic Pingback. Simple Pingback consists of a single
XML-RPC call, while Generic Pingback allows for other methods of
notification.
Server Autodiscovery:
[Inclusion of Simple/Generic distinction. HTML/XHTML differences are
incidental, I don't think the '/' needs to be mentioned.]
Pingback-enabled pages MUST be valid HTML or XHTML documents containing a
<link> element in one of the following two forms (examples given in HTML):
<link rel="pingback" href="http://www.example.com/xml-rpc.php">
<link rel="pingback-generic" href="http://www.example.com/pingback.xml">
Pages must contain at most, one of each type.
Optionally, authors may also serve Pingback-enabled documents with a
corresponding x-pingback header, of one of the following varieties:
x-pingback: http://www.example.com/xml-rpc.php
x-pingback-generic: http://www.example.com/pingback.xml
The inclusion of HTTP headers is recommended, but not required. If they are
included, they MUST match the information given in the <link> element
exactly.
Simple Pingback:
This is indicated by the <link rel="pingback"> element or x-pingback HTTP
header. It contains an absolute URI that specifies the location of the
XML-RPC server that handles Pingback requests for that document.
Generic Pingback:
This is indicated by the <link rel="pingback-generic"> element or
x-pingback-generic HTTP header. It contains an absolute URI that specifies
the location of a Pingback Notification Description document. This
document contains the information on what methods are available to transmit
notification of linking.
PND File Format:
A Pingback Notification Description is an XML file containing zero or more
<interface> elements that describe various methods of notifying a website
that you are linking to a document. An example would be:
<?xml version="1.0"?>
<pingback version="0.9.2-jd">
<description>
This is a Pingback Notification Description for Example Blog. For more
information, see http://www.example.com/pingback/
</description>
<interface priority="3" type="xml-rpc"
location="http://www.example.com/xml-rpc.php" />
<interface priority="2" type="email"
location="mailto:pingback@example.com" />
<interface priority="1" type="manual-email"
location="mailto:feedback@example.com?subject=Link%20Notification" />
<interface priority="0" type="error-reporting"
location="mailto:pingback-errors@example.com" />
</pingback>
Here, the file specifies that there are three different methods of informing
a site that they have been linked.
Each method has an associated priority, which indicates the order in which a
client should attempt them. Clients should parse the file, and attempt to
use the interface with the highest priority first. In the case of a client
not implementing a certain type of interface, or an interface failing, a
client should move on to the next highest priority interface. In the case
of two priorities being equal, the client may determine which interface to
attempt first. When a successful notification has been sent, processing
should end.
The file also specifies an error handling interface, with a priority of 0.
Under normal circumstances, any interface with a priority of 0 should be
ignored, but if a client attempts to use an interface and fails, it may
optionally send details of the failure through an interface defined with a
priority of 0 and a type of "error-reporting".
Interface Types:
HTTP GET Interface:
This type of interface is implemented by sending an HTTP GET request to the
URI specified in the location attribute. The client indicates the location
of the linking document by placing it in the Referer: HTTP header of the
GET request.
XML-RPC Interface:
[As previous version]
Email Interface:
This interface is implemented by sending a specially formatted email to the
address specified in the location attribute. The format of such a message
is yet to be defined. The URI MUST be specified in a mailto: scheme.
Manual Email Interface:
This interface is required where an author is unable to set up any automatic
method of storing Pingback notifications. The Pingback client should send
an email to the address specified in the location attribute that contains a
message formatted for a person to read. The URI MUST be specified in a
mailto: scheme.
Error Reporting Interface:
This interface is also designed for communication with a human. The URI
SHOULD be specified in a mailto: scheme.
Appendix A:
Recommended method for retrieving pingback information. To be completed.
Appendix B:
DTD for PND. To be completed.
Notes:
For the GET interface, is the reliance on REFERER too restrictive? Are
proxies going to get in the way? This is *exactly* what it's designed for,
so I think we should use it.
What do you think of the email interface? I like this, as you can defer
processing to another time (for instance, you could do everything in a
batch, daily). This would also be useful for people on dialup with static
blogs.
Are the error-handling and description bits necessary? I'm not sure.
What do you think of the "priority" bit? I think it's the best balance
between simplicity and utility.
- --
Jim Dabell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9e5FO3tJNldoQhi8RAs22AJ9iG/WMCDJb0OsFXq8UrwlFbFRzDACgiauK
JVYDtQ+CDPH59qBeiwz8Z0U=
=EE/v
-----END PGP SIGNATURE-----
Message sent over the Blogite mailing list.
Archives: http://www.aquarionics.com/misc/archives/blogite/
Instructions: http://www.aquarionics.com/misc/blogite/
This archive was generated by hypermail 2.1.5 : Sun Sep 08 2002 - 22:05:00 BST