NOTA DEL TRADUCTOR: los posibles errores presentes en este documento,
debidos a la traducción, son responsabilidad del traductor y no son
achacables en modo alguno los autores de la especificación, Ian Hickson y Stuart Langridge. Para cualquier
comentario sobre la traducción dirijanse a Ignacio Javier "igjav". La
única versión normativa oficial de este documento es la versión original (en inglés):
http://www.hixie.ch/specs/pingback/pingback-1.0
Las únicas versiones oficiales de esta especificación son las versiones originales (en inglés), citadas a continuación:
© Copyright 2002 Stuart Langridge e Ian Hickson.
Pingback es un método dirigido a autores de la web para requerir notificación cuando alguien enlaza con uno de sus documentos. Normalmente, el software de publicación de documentos web informará automáticamente a las partes implicadas de parte del usuario, permitiendo la posibilidad de crear enlaces automáticamente a los documentos referentes.
Por ejemplo, Alicia escribe un artículo interesante en su bitácora. Entonces Roberto lee este artículo y comenta acerca de él, enlazando con el artículo original de Alicia. Usando pingback, el software de Roberto puede notificar automáticamente a Alicia que su envío ha sido enlazado, y el software de Alicia puede incluir esta información en su sitio web.
Esta es una especificación estable. Son bienvenidos los comentarios en la lista de correo Blogite (archivada).
Actualmente se conocen seis desarrollos prácticos diferentes de esta especificación, aunque no se han hecho pruebas formales para probar en que medida se adaptan a la especificación:
Se incita a los autores a hacer pingback
http://www.hixie.ch/specs/pingback/pingback para registrar sus desarrollos prácticos.
La versión en Inglés de esta especificación es la única versión normativa. De todos modos, para traducciones de este documento, ver http://www.hixie.ch/specs/pingback/translations/. Las traducciones disponibles actualmente son:
El sistema de pingback es un camino para una bitácora web de ser automáticamente notificada cuando otros sitios web enlazan con ella. Es enteramente transparente al autor del enlace, no requiriendo intervención del usuario alguna para su funcionamiento, y opera en base a principios de descubrimiento automático de todo aquello que necesita conocer. Un envío de bitácora de ejemplo, en el que esté involucrado pingback, podría desarrollarse de la siguiente manera:
Habilita enlaces inversos (hiperenlazado inverso) — una manera de regresar por una cadena de enlaces en vez de simplemente hacer introspección.
El mecanismo de pingback usa una cabecera HTTP y un elemento <link> de HTML o XHTML para descubrimiento automático, y usa una simple llamada XML-RPC para notificar al sitio web de destino, del enlace realizado desde el sitio de origen.
Se pretende que los clientes pingback conformes y los servidores pingback sean programables con un esfuerzo mínimo usando bibliotecas comunmente disponibles en entornos de CGI. Por esta razón, los requerimientos de filtrado/análisis de cabeceras HTTP y documentos HTML se han mantenido a un nivel de mínimo imprescindible.
Las palabras clave "DEBE", "NO DEBE", "REQUERIDO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE", y "OPCIONAL" en este documento, con sus respectivas variantes en plural y/o reflexivas, donde sea aplicable, poseen intrínsecamente la interpretación de sus términos análogos en inglés:"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" (por ese orden), que se describe en [RFC 2119].
Existen dos mecanismos para efectuar el descubrimiento de servidores
pingback de manera automática o automatizada: el elemento
<link> de HTML (o XHTML) y las cabeceras HTTP. Un recurso habilitado-pingback DEBE servirse con una cabecera HTTP X-Pingback, o bien contener un elemento <link>,
o ambas cosas. Las páginas HTML y XHTML
habilitadas-pingback DEBEN ser válidas. Los clientes
PUEDEN rehusar a buscar información de pingback en
páginas no válidas.
Téngase en cuenta que la manera en que el cliente es informado de las URI de origen y destino está fuera del ámbito de esta especificación. Normalmente los sistemas de bitácora extraerán los enlaces o hipervínculos externos de los envíos que están siendo preparados para su publicación, para de ese modo encontrar los URI de destino.
Los recursos habilitados-pingback PUEDEN ser devueltos con una cabecera X-Pingback HTTP. Por ejemplo, una imagen PNG servida con las siguientes cabeceras sería habilitada-pingback:
HTTP/1.1 200 OK
Date: Sun, 08 Sep 2002 15:05:37 GMT
Server: Apache/1.3.26 (Unix)
Last-Modified: Thu, 28 Dec 2000 03:18:26 GMT
ETag: "65044-15b9c-3a4ab102"
Accept-Ranges: bytes
Content-Length: 88988
Connection: close
Content-Type: image/png
X-Pingback: http://charlie.example.com/pingback/xmlrpc
.PNG...
El valor de la cabecera X-Pingback DEBE ser el URI absoluto del servidor XML-RPC de pingback.
Las páginas o recursos NO DEBEN incluir más de una
cabecera de ese tipo. Los documentos HTML y XHTML PUEDEN incluir
un elemento <link> por
añadidura a una cabecera HTTP, aunque no es aconsejable. Si es
incluida, la cabecera DEBERÍA tener exactamente el mismo
valor que posea el elemento <link>. En caso de discrepancia de valores, la cabecera HTTP DEBERÁ sobrescribir el valor del elemento
<link>.
De todos modos, los autores de documentos deben estar alerta del hecho
que algunos clientes nos procesarán las cabeceras HTTP debido a
limitaciones de su entorno operativo.
Los recursos habilitados-pingback NO DEBEN usar la cabecera HTTP
Link para anunciar servidores de pingback. Las cabeceras HTTP
Link
requieren un filtrado/análisis no trivial, y han sido por tanto
juzgadas como técnicamente demasiado cargantes para los
propósitos de descubrimiento automático de servidores
pingback.
Una página habilitada-pingback, en HTML o XHTML, PUEDE contener un elemento
<link> en una cualquiera de las siguientes formas:
<link rel="pingback" href="servidor de pingback">
<link rel="pingback" href="servidor de pingback" />
En caso de ser usado, el elemento link DEBE cuadrar la forma apropiada de manera exacta (incluyendo el espacio en blanco antes de la barra diagonal (slash), por ejemplo).
Las páginas NO DEBEN incluir más de uno de tales elementos, y NO DEBEN incluir ninguna cadena que cuadre el patrón descrito más abajo, a no ser que se trate del elemento link concreto.
El descriptivo servidor de pingback DEBE ser reemplazado por el URI absoluto del servidor XML-RPC de pingback. Este URI NO DEBE incluir entidades distintas de &,
<, >, y ".
Otros caracteres que no sean válidos en el documento HTML o que
no puedan ser representados en el character encoding del documento
DEBEN ser salvados usando el mecanismo %xx
(URL escape, comúnmente) tal como describe el [RFC2396].
Estos requerimientos tan estrictos, tienen como propósito el reducir significativamente los requerimientos en clientes que implementen descubrimiento automático de servidor. Fue estimado que requerir a los clientes la inclusión de un filtro/analizador de HTML aparte de un filtro/analizador de XML era una carga demasiado pesada, desde el momento en que sería muy sencillo para autores de páginas web cumplir con las restricciones dadas y descritas previamente.
Los Clientes de Pingback, dados un URI de origen y un URI de destino, DEBERÍAN recoger el URI de destino y seguir los siguientes pasos para encontrar el URI del servidor de pingback.
X-Pingback,
entonces el valor de la primera de las citadas cabeceras debería
ser usado como el URI del servidor de pingback. Los clientes DEBEN
examinar las cabeceras HTTP si les es posible hacerlo. Si por alguna
razón las cabeceras HTTP no están disponibles en el marco
del desarrollo, entonces este paso se puede saltar. De todos
modos, los implementadores deberían ser conscientes que este
hecho reducirá la utilidad de su aplicación, ya que los
elementos link no pueden, en esencia, ser usados en recursos web que no
sean HTML ni XHTML, y las cabeceras HTTP, por definición,
sobrescriben los valores de los elementos link, lo que es
significativo en caso de que su valor difiera.<link rel="pingback" href="([^"]+)" ?/?>
& por &, < por <,
> por >, and
" por ").Una vez extraído este URI correspondiente al servidor de pingback, DEBERÍA ser usado para enviar una solicitud XML-RPC como se describe posteriormente.
Si no hay cabecera X-Pingback y la expresión
regular no cuadra, entonces el destino en cuestión no soporta
pingback tal como es definido en esta especificación y el
cliente PUEDE hacer lo que quiera. De todos modos, SE RECOMIENDA que
los clientes no intenten ser más benevolentes (p. ej. efectuando un análisis/filtrado correcto del
HTML y buscando elementos <link>
que aparenten links de pingback desde el punto de vista de HTML) porque
esto tendrá como consecuencia que ciertos sistemas reconozcan
donde otros simplemente ignoren.
Los clientes PUEDEN optimizar la búsqueda. Por ejemplo:
<link> solo pueden aparecer en la cabecera del documento, los clientes PUEDEN abortar el proceso cuando las cadenas de texto
</head> o <body> sean encontradas
(p. ej. si el cliente lee el contenido línea a línea).Content-Range para recuperar únicamente una pequeña parte inicial del URI de destino.Téngase en cuenta que, de todos modos, estas optimizaciones son propensas a obviar documentos legítimos, por ejemplo, aquellos que tengan comentarios conteniendo las cadenas de texto descritas anteriormente, o aquellos con considerables hojas de estilo en línea que aparezcan situadas justo antes del elemento link de pingback. Se alienta a los autores a tener muy en cuenta estas posibles optimizaciones cuando decidan donde situar sus links de pingback.
Los clientes de pingback, una vez hayan
descubierto un servidor de pingback, DEBERÍAN enviar al servidor
una solicitud XML-RPC con el nombre de método pingback.ping y dos argumentos, el URI de origen y el URI de destino, respectivamente. [XML-RPC]
pingback.pingLos servidores DEBEN responder a esta llamada a procedimiento o bien con una cadena de texto simple o bien con un código de fallo.
Si la solicitud de pingback es exitosa, entonces el valore de retorno DEBE ser una única cadena de texto, conteniendo tanta información como el servidor juzgue útil o conveniente. Es de esperar que esta cadena únicamente sea usada para depuración.
Si el resultado no es exitoso, entonces el servidor DEBE responder con un valor RPC de fallo. El código de fallo debería ser, o bien uno de los códigos anteriormente citados, o bien el código genérico de fallo cero si el servidor no puede determinar el código de fallo apropiado.
Los clientes PUEDEN ignorar el valor de retorno, haya sido o no exitosa la solicitud. SE RECOMIENDA que los clientes no muestren los resultados de las solicitudes exitosas al usuario.
Ante la llegada de una solicitud, los servidores PUEDEN hacer lo que quieran. De todos modos, SE RECOMIENDA seguir el siguiente procedimiento:
Para pretender la conformidad con esta especificación, un cliente de pingback DEBE soportar descubrimiento automático de servidor tal como se describe en esta especificación, y DEBE enviar correctamente solicitudes XML-RPC de pingback.
Para pretender la conformidad con esta especificación, un servidor de pingback DEBE ser capaz de recibir solicitudes XML-RPC de pingback y siempre DEBE devolver resultados que estén en conformidad con los valores de retorno permitidos. La devolución de códigos de fallo detallados (no cero) es OPCIONAL.
Nótese que algunos servidores de pingback pueden no tener
páginas asociadas. Por ejemplo, un servidor de pasarela pingback
podría ser de tipo "standalone", es decir, dedicado, y otras
páginas usarían el elemento link para enlazar con esta
pasarela en vez de proveer un servicio de pingback doméstico.
Para pretender la conformidad con esta especificación un recurso habilitado-pingback DEBE tener, o bien una cabecera HTTP
X-Pingback, o bien un elemento link de modo que se permita el descubrimiento automático de servidores.
Para pretender la conformidad con esta especificación, un agente de usuario pingback DEBE soportar descubrimiento automático de servidor tal cual ha sido descrito en esta especificación, DEBE enviar correctamente solicitudes XML-RPC de pingback, DEBE ser capaz de recibir solicitudes XML-RPC de pingback, DEBE devolver siempre resultados que se ajusten a los valores de retorno permitidos (la devolución de códigos de fallo detallados (no cero) es OPCIONAL), y DEBE tener, o bien una cabecera HTTP
X-Pingback, o bien un elemento link
en todas las páginas de destino potenciales, para de este modo
permitir el funcionamiento del descubrimiento automático de
servidores.
A continuación se ofrece una observación más detallada acerca de lo que podría ocurrir entre Alicia y Roberto durante el transcurso del ejemplo descrito en la introducción.
http://alice.example.org/#p123, y el URL del enlace a la bitácora de Roberto es
http://bob.example.net/#foo.http://bob.example.net/#foo.X-Pingback, pero no la encuentra.<link rel="pingback" href="http://bob.example.net/xmlrpcserver">Si la página no hubiese contenido esta marca, entonces la bitácora de Roberto no soportaría pingback, y entonces el software de Alicia abandonaría aquí (desplazándose al siguiente enlace encontrado en el paso 2).
http://bob.example.net/xmlrpcserver:
pingback.ping('http://alice.example.org/#p123', 'http://bob.example.net/#foo')
Aquí finaliza el trabajo a llevar a cabo por el sistema de Alicia. El resto del trabajo lo realizará el sistema de bitácoras de Roberto.
http://alice.example.org/#p123
(la dirección que enlaza con Roberto) y
http://bob.example.net/#foo (la página con la que Alicia enlaza).http://bob.example.net/#foo es, de hecho, un envío en su bitácora.http://alice.example.org/#p123, y chequea el
Content-Type de la entidad devuelta con el propósito de asegurarse que es algún tipo de texto.http://bob.example.net/#foo (esto se hace para prevenir envíos masivos de pingback).