Introduce the property parameter #1
Comments
|
Cool idea. I think if folks want to start sending linked data in webmentions (which I think is worth exploring), we should focus on supporting proven linked data content types to support it (JSON-LD, Turtle), not add new parameters to the 'application/x-www-form-urlencoded'. I've never seen x-www-form-urlencoded linked data. The example that's a 'placeholder' in the property input of the form at http://csarven.ca/webmention is 'sioc:reply_of'. In the case where the source self-reports as a reply, this can just be fetched from the source resource. So it seems like this is only needed if a third party (that doesn't operate |
|
Webmention has been implemented in linked data in the form of "Semantic Pingback" http://www.w3.org/wiki/Pingback#Semantic_Pingback In fact webmention was partially based on this protocol. I'd suggest to use namespaces for source, target etc. from the pingback vocab if wishing to implement this in the linked data world. Alternatively putting something under w3.org/ns could work. Pingback has been implemented before in "my-profile" project and a couple of others. |
That is a good idea, though now we have drifted away from the name of this issue, which is proposing a new property in the application/x-www-form-urlencoded Content-Type I made #2 to rationalize. |
|
I think this would make a fine extension. I don't see any situation where property is really needed though. With the target, you can discover the relationship. Its really just giving a hint to processing which is why I would say it shouldn't be part of the base spec. In addition I think the term "property" would be better replaced with something more descriptive, "relation" perhaps. But I know there are better vocabulary experts in the group. I know that can be a deep rabbit hole :) I think an additional extension could be done for format to tell the receiver the data can be fetch by "mf2", "as2", etc |
|
If we want to talk about what is strictly required, it is just the source. If we want to continue talking about how to let the target know precisely why a target was mentioned, then you need both property and target. Both property and target help with the validation process. If you want to discuss in terms of "extensions", then everything outside of source is an extension. source is a MUST, property is a SHOULD, target is a SHOULD. If the parameter names are up for renaming, then we use something more descriptive, replace source with subject, and target with object. Otherwise, all the terms; source, property, target, are already used in practice. Edit: 2015-11-30T19:20:00+01:00 , I'd be okay with My real-world implementation feedback here is that, all three parameters are integral to making webmention work to its full potential. That is, to start a sensible discovery and validation process, as opposed to plumbing centric arbitrary imperative programming. In contrast, using all three parameters is the declarative approach. |
|
I think target is a MUST, as it is not clear by inspection how many URLs the endpoint covers, so indicating the target for the mention is key if you want it to be accepted. This is not just true for a given website, but for services like webmention.herokuapp.com and webmention.io that accept webmentions for URLs on many web sites. I agree property is an optional extension. |
|
The same argument can be made for the property, hence it is a MUST. It is equally possible to have different relations between the same source and the target. Keeping property and target as SHOULDs is workable and encouraged. If we want to ensure no ambiguous mentions are made, then property and target are MUSTs. The 3rd party centralized services like the ones you've mentioned above are not of interest or of concern here. A property is a fundamental part of a mention. It is part of the data. It is a way for the target to better figure out if/how they want to process/validate the mention. Target is already prepared to find the claimed pattern. The property is a simple indicator to use and watch out for. It helps. If you haven't implemented the property parameter, I suggest experimenting with it first to get a real-world experience on what's really happening. Report back with your webmention endpoint. |
|
Eppur se muove: - I have webmentions implemented across multiple sites using a variety of services that both send and receive them. None of them support the 'property' extension, so it is clearly not a MUST. https://webmention.herokuapp.com/api/mentions?site=kevinmarks.com&format=html https://webmention.herokuapp.com/api/mentions?site=svgur.com&format=html |
|
The point about having you implement the property parameter is so that you understand better how it works. I hope I don't have to repeat myself, but please understand that, target is not a MUST either. What you think applies to target equally applies to property. So, if you want to go ahead and think property as an extension, that's fine. Understand that, target is also an extension using the same arguments. I've stressed this point numerous times. Again, 3rd party centralized services are irrelevant. What's going to happen is that, the WG is going to take an existing mechanism (i.e., in this case webmention) and update it as it needs to fulfil its needs. If this repository is or planned to be about IWC's attempt to claim webmentions, then I propose that work gets carried outside of W3C, alternatively (and I sincerely hope that it doesn't come to this) but we rename this repository to iwc-webmention, and create w3c-webmention which can be a well-rounded understanding of the problem based on implementation experience. I have asked you to go ahead and implement it so that we are on the same page in the discussion. To have a balanced look at webmention, we are going to have a look at it to serve everyone's - at minimum W3C Social Web WG's as a whole - needs. This is not about your particular implementation or IWC, or whatever support or features some 3rd party services are providing. Having said all that, I think the best way forward would be: source is a MUST, property is a MUST, target is a MUST. source makes precise claims about the mention, target knows precisely what to look for. Period. |
|
So, I implemented a webmention receiver from scratch at http://mention-tech.appspot.com/ |
|
@kevinmarks , thank you for implementing the property parameter. I can confirm from my implementation at http://csarven.ca/webmention that target is not required. It works without it. I am able to receive and process without target. My implementation can process given source as minimum. If property and target are provided, great. Processing and decision making is even easier, better and accurate. Moreover, the webmention you've made to my endpoint, i.e., Furthermore, please note that the value of property can be anything. Perhaps more specifically what I proposed was: "Its value may be a term e.g., |
|
I'd rather see property required than target optional. Could a compromise be a default value for property for those who wish to send a 'vanilla' mention or a mention with an ambiguous relationship? They must send property=mention/link/href/null ? |
|
Target optional is a mistake, yes. If csarven can ignore it in his special case, that is not true of many other implementations. But that is a false dichotomy - property is completely redundant and highly confusing to complete; it requires you to know the receivers' parsing model to fill in, which is bad coupling. |
|
well, I just tried with u-in-reply-to and rel="vote-against" and got 403 Forbidden each time |
|
I prefer to see all three. It only improves the quality of the webmention. All three components are integral to the claim that's being made. Something is referring to something in a particular way. More specifically: since the context is mentions, we are dealing with something along the lines of |
|
From a non-technical point of view, I hope that |
|
Kevin, please refrain from adding new information to the existing comments you've made, right after reflecting on the comments which were made after yours! Create a new comment instead. That's just being polite and easier for people to follow the conversation. Regarding your statement: "requires you to know the receivers' parsing model", that's completely misleading if not completely misinterpreting what I'm proposing. The source can make a relation to the target as it needs to, and informs the target about it. Period. There is no further requirement, there never was. What's the intention for pulling an argument like that out of thin air? re: http://known.kevinmarks.com/2015/as-far-as-i-can-tell-webmention-returns-403-to . Your 403 issue was temporary. See also http://csarven.ca/webmention#i-20151128131129 . And I'm quite certain that you did not try "all property vales". If you have, please provide proof. |
You don't need to know anything about the receiver, only how you mark up your own documents. The property you send is yours, not theirs. If they don't understand it, no biggie, up to them to decide whether to process anyway (as it currently is - internal logic to decide when/if/how to verify is assumed already - but they can now choose to skip even parsing documents with properties they don't understand). Discovering what the receiver expects would be a handy extra step if you wanted to implement it, but not required by any means. |
|
Note: if one allows something like #11 "clarifying URLEncoding Parmeters", then one could add new relations at any point in time without trouble. |
|
Anyone can add new properties at any time by marking up their source #11 indicates that "without trouble" is defined by Henry in some personal
|
|
@kevinmarks how do I know with urlencoded parameters what the meaning of a new key value pair is? In normal forms generated for the web from the 1990ies the form is generated by the same Origin as the the resource consuming the attribute values. In that case the agent writing the interpreter of the form is the same as the one creating the form. There is therefore no problem of communicating meaning across contexts. On the other hand in the case of a distributed protocols, where a software agent is about to send a message to another Origin, things are very different. In that case the author of the form and the consumer are different. In that case context matter. A simple way to get to grasp this problem is to ask the following questions: how does that agent know
The fact that there is a difference between these two situations is well understood on the web, and its security implications are written down in the CORS specification. If you try working across origins in JavaScript you will soon get to discover these limitations. ( What I mean by "without trouble" is that anyone in the future that wants to specify that their endpoint can understand new parameters can advertise it in a way that is machine parseable and consistent across origins. ) |
|
As far as I can tell all the HTML specs punt on what servers should do w3c HTML5 says
The closest thing to a spec I could find was in the old CGI docs which gives implementation pointers and then says:
Which is very Postelian. |
|
@kevinmarks yes, exactly. Note especially: "and then do what you like with them", which underlies my previous point. |
|
I'd say that nearly 20 years without a spec more formal than that indicates that we may not need one, given how much has been built on it, theoretical drone strikes notwithstanding. |
|
So going back to the original point here, there are 2 proposals. 1) make target optional and 2) add a new property parameter. Lets take taking target as optional first. I think @kevinmarks has a perfect example of anything doing webmention handling as a service being a key place where it is needed to always be there. This is a perfectly valid use-case and likely an important one. I can see this being the same issue for any site that has multiple users (silos even),especially for ones that allow custom domains for users. Moreover this would significantly effect processing of anything that refers to more than one URL. If you mention 1000 URLs in a list of "top 1000 URLs on subject X" you have to check ALL 1000 to see if ANY url you are managing is in there. When given the target URL you can easily verify that you actually care about the URL and that it is referenced by the source. For the new property parameter, I don't see it makes sense when passing the type of relation. You could do this, but this should be immediately discernible after fetching the source. And this data can easily be given incorrectly. If I receive a webmention that says it is a "Like" but I refer to the source and its actually a reply, should I dismiss the webmention because the claim of it being a like is incorrect? This also adds the dangerous slope of implementers simply skipping the verification step. "I got a webmention and it says its a like, I don't care what's at the source, I'll just display that I got a like from that link". Without the Property parameter, you are forced to fetch the source and validate the claim. Now I do think there is room for another parameter such as "encoding" which will let the receiver know exactly what format the source should be fetched via. specifying "mf2" or "as2" or "jsonapi" etc. This is somewhere that there actually is a difficulty as you may just receive some JSON and not know exactly how processing should be handled. If I don't support that processing I can just drop the webmention immediately, but if I am able to parse that format, I still have to fetch the source. Think of it as anything that is authoritatively found at the source should be ONLY at the source and never in the webmention itself. |
|
re #1 (comment) clearly I did not try all possible property values as that would both constitute a DDoS and violate the halting problem. All the values I tried, including the ones you expressly suggested gave a 403. That http://csarven.ca/interactions listed everything from 2014-11-13 onward as unverified/anonymous implied the problem was widespread. This does represent another flaw in the proposed 'property' parameter. A webmention sender can retry with the same source and target, and expect the receiver to treat it as an update to the original mention. Indeed, 3rd parties can send webmentions to notify of ones that have been dropped. If the 'property' only exists at the point of posting, then that is not an option, or rather it would require the sender to parser the source specifically. If multiple webmentions with matching source and target are sent but with different 'property' what is that supposed to do? |
|
This issue is about the property parameter - we should split 'make target optional' into a separate issue. |
|
Making target optional was based on the fact that property and target are not absolutely needed, i.e., an endpoint can still be operational (one counter-example to the raised "issue" against that was: my http://csarven.ca/webmention endpoint). The proper way forward is to provide both property and target. I was not advocating for target being optional any more than property being optional. They are equally valuable, which is why I last suggested that all source, property, and target should be MUSTs: #1 (comment) , on the basis that having all three represents the complete information of the webmention claim. source, property, target are strictly part of the data. Stuff like vouches are extensions because they are outside of the data. I hope that fundamental difference is clear. |
|
re: #1 (comment)
Yes, that's the whole point of a verification. Having said that, you do whatever you want to do.
Huh? Implementers will do whatever they want at the end of the day. I've explained at #12 (comment) that it is obviously possible and will even happen given that two parties have established trust. If you disagree, please provide evidence for "dangerous slope". |
Receiver's call, I presume, as with all decisions regarding whether or not to verify a mention.
I don't know that implementors knowingly violating the spec is anything we can solve in the spec itself. |
|
Edit: I apologize for my tone in the original version of this comment. re: #1 (comment) : http://csarven.ca/interactions is a manually moderated list of received mentions. Just displays from my database, no part of the webmention spec is implemented here. Mentions which have not been approved show as anonymous, and I haven't got around to approving them yet. It's not useful to base any assumptions off this page. |
|
On Sat, Nov 28, 2015 at 2:33 PM, Sarven Capadisli notifications@github.com
As your endpoint is the only implementation of your proposed 'property'
|
|
There was a good discussion about this in IRC yesterday. The thing that finally clarified the actual benefit for me is that a source link may contain multiple kinds of links to the target, such as when someone posts a "repost" and "like" in the same post. Currently, most webmention implementations choose an arbitrary order when looking for the specific relation of source to target. Adding this property means the receiver only has a single thing to look for to verify the webmention. That said, I am strongly opposed to requiring the property in the core spec, given that the existing webmention implementations manage to get by fine without it. I think this would make a great extension to the spec, since it does benefit the receiver and is not much of an extra burden on the sender. |
|
We don't have to decide on this right away anyway do we? Perhaps it's worth making a note of it in the spec (or feature at risk?) whilst we iron out other things, and try (hope!) to get implementors with a broader range of needs over the next while and revisit. |
|
It needs much more clarification of what it consists of. Is it a rel value, a class, or what? |
|
+1 for rel added as MAY |
|
After discussing it in the F2F today, we came to the conclusion that this would be best as an extension, since it has the potential to introduce quite a bit of bulk to the spec. Additionally, there is already precedent for adding new things to Webmention starting out as an extension. I will update the spec to link to extensions like Vouch and this one if it is written up as an extension. I would very much like to see this written up as an extension, and then link to it from the webmention spec, and ask for implementation feedback on it from others. Link to IRC logs: http://www.w3.org/2015/12/02-social-irc#T18-34-34 |
Document and incorporate the idea of using properties as a parameter to better employ webmentions.
This was already documented and mentioned here:
http://csarven.ca/webmention
in which the IWC community is well-aware of (let me know if citations are needed). And, here on the Social Web WG mailing list:
https://lists.w3.org/Archives/Public/public-socialweb/2015Jul/0092.html
and several times on IRC #social . Let me know if citations are needed on that.
If this repository is strictly about IWC's webmention, then I propose renaming it.
The text was updated successfully, but these errors were encountered: