W3C Social Pingback

[gobengo]

webmention is cool and I like it.

However, I think we need more to really make progress on the "Federation Protocol" deliverable mentioned in the charter.

Other than webmention, LDP is the other protocol mentioned in the charter as a 'possible input' to that deliverable, but it doesn't help prescribe much that helps with webmentions or pingbacks (that I can tell).

@melvincarvalho points out the similarity between webmention and something many of us have worked with for over a decade

Webmention has been implemented in linked data in the form of "Semantic Pingback" http://www.w3.org/wiki/Pingback#Semantic_Pingback

Notably, (AFAICT) the W3C has never produced a Pingback standard. The closest thing to a standard I can find is "Pingback 1.0" hosted on hixie.ch (Ian Hickson, WHATWG).

hixie is rad, and an editor of HTML5. But link rel pingback is not specified as part of HTML5. http://www.w3.org/TR/html5/links.html#linkTypes

So Pingback is not a standard we have to adhere to.

But I think there are some important questions to answer if we want the "Federation Protocol" to be a CR, and not just a Note: Why throw away 13 years of implementations and start from scratch? Can we salvage Pingback 1.0 into a W3C specification that is similar, but also modern enough to drive adoption of web federation for at least another 13 years (perhaps with a logical major version bump, '2.0')? The answer is not obvious.

The following two sections/lists are meant as starting points. Please suggest additions

Update. I have strikken through points where I was wrong, which were numerous..

Here are things that Pingback deals with that Webmention currently doesn't

• Discovery via HTTP header, not just HTML (As @aaronpk points out, webmention does have this)
  • This is nice because clients can discover via HEAD requests without having to download/parse HTML
  • Response headers can sometimes be hard for some publishers to implement. well-known URIs and/or webfinger aim to help with this.

Here are things that I personally don't like about the idea of implementing Pingback 1.0 in this era of the web

• "Pingback-enabled HTML and XHTML pages MUST be valid." seems unneccessarily strict, especially considering the regex mentioned in the service discovery section
• XML-RPC Interface is the only ping mechanism described, which is a MUST for conformance
  • "To claim conformance to this specification a pingback server MUST be able to receive pingback XML-RPC calls"
  • Many young web developers have never worked with XML-RPC. Some never even XML. Instead, many developers are more comfortable with these mimetypes:
    • application/x-www-form-urlencoded - Like webmention today
    • LD Syntaxes - As seen in the AS2 and Web Annotation communities, it's possible that all these can be covered with only a syntax-agnostic vocabulary (perhaps >= "http://dssn.org/pingback/ns/namespace.html")
      • application/ld+json - http://www.w3.org/TR/json-ld/
      • application/activity+json - http://www.w3.org/TR/activitystreams-core/
      • text/turtle - http://www.w3.org/TR/turtle/
    • application/json - https://tools.ietf.org/html/rfc7159
      • This could be covered with a recommended way of framing the JSON-LD vocabulary with standard key strings, e.g. just { "source": "url", "target": "url" }. The Activity Vocabulary is doing this nicely.
  • If I had to pick one of these to be a MUST for conformance, I'd pick application/x-www-form-urlencoded just like Webmention does today.

I expect this to stoke some strong opinions, but I believe it illustrates the possibility of a Middle Way to a Federated Social Web that doesn't ignore past efforts (webmention didn't ignore it) abandon existing pingback markup, and also considers the current uses and extensibility benefits of linked data.

If this is well-received, I could try to draft something that addresses these issues while attempting to be very close to a superset of Webmention and Pingback 1.0.

[bblfish]

I co-authored a partial history of pingback

• having relations tie in to syntax such as xmlrpc is a good example of why doing that is a bad idea
• pingback is not defined in the Link Relations page

I think if one can find a way for semantic pingback to be defined so that it satisfies the indieweb crowd, LDP and Federated group, that would be great. For the LDP we want to be able to build powerful tools that can follow links, and do the right thing, without having to write 1000 of special cases.

I suppose that if people now agree on JSON-LD (which should be just thought of as one syntax among many other possible ones, eg: Turtle, RDFXML ( sigh!), ... so that in 10 years the standard can just be adapted if another syntax comes along as the trendy one) what is needed is:

1. the name of a link relation
2. a description of the type of structure one can POST to the container. Should it even be limited? With LDP that can actually be determined by the LDPContainer pointed to, and the spec for doing that is not yet finished at the W3C.
3. Access control is actually an orthogonal topic, so it need not feature as part of this either.

[dret]

On 2015-11-25 10:17, Henry Story wrote:

I suppose that if people now agree on JSON-LD what is needed is

1. the name of a link relation
2. a description of the type of structure one can POST to the container.
   Should it even be limited?

ideally not. link relations communicate why an application/user may
want to follow a certain link (if i want to accomplish application goal
x, then at this point in the control flow i need to follow link with
relation y). how the interaction then plays out is a different issue and
can use standard HTTP mechanisms such as content negotiation.

it is possible to register a relation type in the same document that
specifies a certain format. but i would say that it would be an
anti-pattern to constrain link relation types to a single media type.

another option is to have a small standalone registration spec and leave
the media type open. if there are existing media types for pingbacks,
such registration could even list (some of) them and say that the exact
format of a pingback is unconstrained, and is determined by context or
through HTTP interactions.

cheers,

dret.

erik wilde | mailto:erik.wilde@dret.net |
| http://dret.net/netdret |
| http://twitter.com/dret |

[kevinmarks]

On Wed, Nov 25, 2015 at 1:17 AM, Henry Story notifications@github.com
wrote:

I co-authored a partial history of pingback
http://bblfish.net/tmp/2011/05/09/

• having relations tie in to syntax such as xmlrpc is a good example
  of why doing that is a bad idea

indeed - maybe an impartial history is needed.

The inventor has adopted webmention now:

http://www.kryogenix.org/days/2014/11/29/enabling-webmentions/

• pingback is not defined in the Link Relations
  http://www.iana.org/assignments/link-relations/link-relations.xhtml
  page

that page is deprecated - the canonical registry is now
http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
which does included pingback

[gobengo]

what is needed is:

1. the name of a link relation
2. a description of the type of structure one can POST to the container. Should it even be limited? With LDP that can actually be determined by the LDPContainer pointed to, and the spec for doing that is not yet finished at the W3C.

I like this simplification as to the underlying components here.

1. 'pingback' and 'webmention' are registered. Either we extend one of those to address all concerns, or address all concerns and register a new one. 'linkback' is not taken.
2. Better than 'the type of structure' is 'a vocabulary' for posting relations. I think the minimally needed set is pingback:source and pingback:target.
   • Any deliverable should also illustrate how to serialize this vocabulary in common mimetypes.

Should it even be limited?

Yes

With LDP that can actually be determined by the LDPContainer pointed to

That will be cool. But most of the web right now is not LD.

• For non-LD mimetypes (where normalization/framing algorithms aren't defined), I think these 'illustrations' should be normative requirements.
  • For application/x-www-form-urlencoded it should be just like Webmention is today.

I also think that a more flexible Service Discovery model is an important 3rd Component of this (@bblfish, as you mention, your 3rd bullet of Authorization/ACL is orthogonal)

1. Link relation to Service
2. Semantics and Syntax (for mimetypes where vocabulary is not sufficient to imply Syntax)
3. Content-Type agnostic Service Discovery - At the very least via Link Header response + bullet 1.

[bblfish]

what is actually needed for LDP folks is a way to transform application/x-www-form-urlencoded into RDF. Something like json-grddl updated to json-ld . That would allow backward compatibility with what exists currently.

Of course the actual mime type should practically be limited to a few. But the data structure should be defined semantically, so that it can survive change of syntax fashions. The vocabulary should be extensible in the RDF way: that is new relations added should not change the meaning of the old relations. This is known as monotonicity, or also "the open world assumption".

[gobengo]

what is actually needed for LDP folks is a way to transform application/x-www-form-urlencoded into RDF.

That is outside the scope of deliverables of this WG, but would be informative to see a consistent proposal on (e.g. with '...%40context=uri')

the data structure should be defined semantically

+1. And I think "http://purl.org/net/pingback/" (or a subset) is sufficient so far. Do you?

[bblfish]

yes, a JSON-LD grddl for application/x-www-form-urlencoded may be outside the scope of thie WG, but its going to come up again and again. It would really help to merge Web1.0 with Web3.0 . Perhaps @msporny knows of such a standard already?

yes, I am fine with http://purl.org/net/pingback ( It's a pitty that the URLs are not hash URLs, but I suppose it will do ).

[dret]

On 2015-11-25 10:37, Kevin Marks wrote:

On Wed, Nov 25, 2015 at 1:17 AM, Henry Story notifications@github.com
wrote:

• pingback is not defined in the Link Relations
  http://www.iana.org/assignments/link-relations/link-relations.xhtml
  page
  that page is deprecated - the canonical registry is now
  http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions
  which does included pingback

the IANA registry is not deprecated. it still is the registry for link
relation types on the web. the HTML5 page has been created in an attempt
to change the IANA process defined in RFC 5988 to something more
lightweight, which was the preferred way to go by the HTML5 community.

[aaronpk]

@gobengo you literally described webmention:

"Here are things that Pingback deals with that Webmention currently doesn't: Discovery via HTTP header, not just HTML"

That is false, Webmention supports disovery in the HTTP header:

The webmention endpoint is advertised in the HTTP Link header or a or element with rel="webmention"

and as for

"If I had to pick one of these to be a MUST for conformance, I'd pick application/x-www-form-urlencoded just like Webmention does today."

I agree, it's simplest, and that's why Webmention uses it.

Basically the whole point of Webmention was to take the existing mechanism of Pingback and remove the unnecessary stuff, mainly the XMLRPC bit. If you were to do the process again I suspect you'd arrive at a spec that is very similar or identical to Webmention. I am confused why you say that Webmention has ignored past efforts.

[gobengo]

@aaronpk you're right on both fronts.

I missed the web mention link header.

And I shouldn't have written "ignore". I moreso meant to just highlight that perhaps it's possible to standardize something that is backward compatible with Pingback markup, but doesn't strictly require XML-RPC.

Apologies for both mistakes. I'll strike through when not mobile.

Sent from the hip

On Nov 25, 2015, at 7:42 AM, Aaron Parecki notifications@github.com wrote:

@gobengo you literally described webmention:

"Here are things that Pingback deals with that Webmention currently doesn't: Discovery via HTTP header, not just HTML"

That is false, Webmention supports disovery in the HTTP header:

The webmention endpoint is advertised in the HTTP Link header or a or element with rel="webmention"

and as for

"If I had to pick one of these to be a MUST for conformance, I'd pick application/x-www-form-urlencoded just like Webmention does today."

I agree, it's simplest, and that's why Webmention uses it.

Basically the whole point of Webmention was to take the existing mechanism of Pingback and remove the unnecessary stuff, mainly the XMLRPC bit. If you were to do the process again I suspect you'd arrive at a spec that is very similar or identical to Webmention. I am confused why you say that Webmention has ignored past efforts.

—
Reply to this email directly or view it on GitHub.

[bblfish]

"If I had to pick one of these to be a MUST for conformance, I'd pick application/x-www-form-urlencoded just like Webmention does today."

I agree, it's simplest, and that's why Webmention uses it.

Yes, so for use with LDP it would be nice to be able to have a translation from application/x-www-form-urlencoded so that we can POST it to an LDPC ( C for Container). It there were an automatic way to decode application/x-www-form-urlencoded then we could just enhance LDPCs in LDPnext, so that webmention posts are correctly understood.

[melvincarvalho]

@bblfish is right. I brought up all these points already in July on the mailing list

https://lists.w3.org/Archives/Public/public-socialweb/2015Jul/0037.html

So I'm confused why the document has not addressed them in a timely way. Additionally given our time line I do not have confidence they will be addressed in time to take this work to REC. As such I think it would be practical to aim for at most a note.

Additionally we probably only have about 24 hours of real telecon time until mid 2016 when the group should be wrapping up. I dont think this new effort is practical and will eat up valuable telecon time, unless progress can be made at the F2F.

The traditional mode of, imho, rail roading dubious proposals, with limited adoption, through the vote stuffing should be opposed, so let me -1 this work strongly here, it terms of it being new work, eating into telecon time at the expense of work that is generally agreed upon by the group.

That said, I do favour the standardization of webmention, hence me starting a thread on the topic in back in July. We could have been ready by now, unfortunately the chair who is most strongly pushing webmention, refuses to read the mailing list, which, imho, has slowed things down. it would not take much work to get this to standards quality. If progress can be shown, particularly at the F2F, I dont see any problem with it, indeed we could publish it by the end of the year.

So in general the problem is that the work is not following existing standards. Namely that predicates ought to be URIs and that the mime type the group is working on (any w3c REC or JSON based).

If there were a standard way of converting form endoded variables into URIs that would help, but I think none exists. A way to do that would need to be chosen or a generic principle applied. I have suggested in the past as a starting point to change names into urn:name, but that would voilate the RFC. A generic process such as this would help, but I dont think we're there yet.

Also we need to change the rel="webmention" into a URI. Perhaps IANA is taking care of this already.

Source and target if we cant find a general way to do it, could use the pingback vocab, and hence allow extensibility somehow.

The values in the source and target should also yield things that are readable by the software in this group, e.g. activity streams or some other JSON format. We can perhaps get away with other formats, that would really be a point of discussion.

In short, lots of issues to be resolved, if there's a willingness to do so, let's work on the actual text to make this into something everyone can use.

[kevinmarks]

dret, both the w3c and WhatWG HTML specifications normatively reference the microformats rel registry rather than the IANA one, so you are factually incorrect. See http://www.w3.org/TR/html5/links.html#other-link-types

[melvincarvalho]

@kevinmarks the entry for webmention on that page is:

https://github.com/converspace/webmention/blob/master/README.md

Which says

the latest, most up-to-date specification is located on the

http://indiewebcamp.com/webmention

But we're also now told to look at:

http://webmention.net/

Quite a mess, especially when someone is trying to do a web search to try and understand what it is about.

[aaronpk]

@melvincarvalho Please refrain from bringing up multiple new issues as a comment on a single Github issue. The great thing about using Github issues for discussion compared to a mailing list is it allows different topics to have their own URLs, so people can participate and follow individual issues. Bringing up new and separate topics within this thread is counterproductive.

Additionally we probably only have about 24 hours of real telecon time until mid 2016 when the group should be wrapping up. I dont think this new effort is practical and will eat up valuable telecon time, unless progress can be made at the F2F.

Yes, the whole point of bringing up webmention on the last call was to be able to discuss and make progress on it at the F2F.

Given that @gobengo has updated his comment (thanks btw), and seeing as this thread has gotten completely off topic, I'm going to close this issue. Feel free to file new issues with specific points that can be discussed.

[bblfish]

@kevinmarks

dret, both the w3c and WhatWG HTML specifications normatively reference the microformats rel registry rather than the IANA one, so you are factually incorrect.

I think that tends to show that the two standard groups are not in sync.

[bblfish]

@aaronpk why not ask @melvincarvalho to move his post to another issue, and leave this one open. I thought it was making good progress.

[kevinmarks]

Which 2? There are 5 involved here. WhatWG, w3c and microformats are in sync on this. IETF and IANA have not caught up yet.

[aaronpk]

@bblfish The original issues were 1) the Webmention should be discoverable by HTTP header (it is), and 2) there are some issues with Pingback, which can be solved by reducing the payload to a form-encoded request (webmention does this). I would really like to encourage more focused threads starting with specific real-world use-cases that are driving the suggested changes.

[melvincarvalho]

@aaronpk -1 to taking this work forward, please see my points on the mailing list. If those issues are addressed and resolved, either here, in further issues or on the mailing list, that would be great. I hope there is enough information to make some progress. But the indication is, IMHO, that issues will be closed without unanimous consent. I look forward to improved revisions based on feedback.

[bblfish]

@kevinmarks

Which 2? There are 5 involved here. WhatWG, w3c and microformats are in sync on this. IETF and IANA have not caught up yet.

There is a process at the IETF by which one RFC gets updated by another. See for example the HTTP RFC. The correct way to move forward would be correct to propose a new Link Relation RFC that updates the old one so people who have been following the IETF RFC don't get mislead.

[dret]

On 2015-11-25 18:20, Kevin Marks wrote:

dret, both the w3c and WhatWG HTML specifications normatively reference
the microformats rel registry rather than the IANA one, so you are
factually incorrect. See
http://www.w3.org/TR/html5/links.html#other-link-types

that is an interesting take on reality and one that is probably not
entirely independent of being invested in microformats. and yes, whatwg
makes a sport out of disliking anything that is not whatwg, and w3c kind
of went along with that because they had no better way to get back into
the HTML game. but that still doesn't change the fact that all of this
is only about HTML, and not about the web as a whole. if you're
interested in the web, then the IANA registry still is the place to go.

[aaronpk]

@melvincarvalho I'm not opposed to discussing your points, I would just really rather discuss this on Github than on the mailing list. Please feel free to open individual issues for each point in that email.

@bblfish, @kevinmarks and @dret: this is not the place to discuss which rel registry is correct.

I am locking this issue because I feel bad for everyone else getting emails and notifications about this continuing discussion.

[csarven]

XXX: This issue was inappropriately closed.

Re-openning the issue on the grounds that 1) it was acknowledged (at least on IRC) that there are relevant/useful issues which could be created in more concise form 2) the individual that acknowledges 1 and still wants to close the issue, needs to take on the workload to create new issues. Therefore, I will re-open this issue and let the conversation continue as it should for the time being.

[tantek]

@csarven that's not new information. @aaronpk closed the issue because the original issue was resolved, thus I'm reclosing. He noted and requested that any other issues be noted as new issues. It is the burden of those that think there are new issues that matter to create those new issues, not aaronpk's burden.

If you or anyone else thinks the tangential commentary in this thread contained issues worth looking at you are empowered to create new focused issues accordingly. Please do not re-open this issue unless it is regarding this specific issue.

[melvincarvalho]

Thanks for the input on this thread. I've unlocked and reopened this as I feel there was not unanimous consent that it should be closed. Please let's not turn this into a lock / unlock war :)

I do agree with aaron that it would be advantageous to isolate and split off items that do not relate specifically to the original points made and split them into new issues. I will try and do this if I get time, or if someone else would like to help, that would be great!

[bblfish]

It is probably indeed worth opening new issues, as the thread is now a bit long. It was not clear at the first closing wether that meant none of the points should be debated, if the initial issues had been settled, if this was off topic for the Group, or if new issues should be opened.

[melvincarvalho]

I've added #9

[gobengo]

I edited the OP to strike through the parts where I was wrong and/or chose bad wording so that further debate isn't on that wrong stuff.

[bblfish]

There are now 3 issues that some of what was discussed here: A good entry point is Lack of Context in Web Mention

[dissolve]

closing this issue as its not open any more, original question was answered, any other issues should be in other issues