2014-08-26 UTC
cmhobbs, bblfish, KevinMarks, ShaneHudson, shepazu, barnabywalters, Shane, Morbus, nicolagreco and jasnell-github joined the channel
# 16:04 jasnell-github w3c-socialwg-activitystreams/master 7d716a3 James M Snell: editorial nits
jasnell-github joined the channel
# 16:05 jasnell-github w3c-socialwg-activitystreams/gh-pages cc8bbfe James M Snell: editorial nits
jasnell, nicolagreco, elf-pavlik and jtauber joined the channel
harry joined the channel
# 16:55 RRSAgent trackbot, access must be one of public, group-strint-submission, offline-webapps-workshop-program-committee, group-webmobile-chairs, group-rdf-val-pc, alumni, group-payment-workshop-submissions, wstar, group-digipub-chairs, member, memberSearchers, group-csv-chairs, wsridirectors, i18n, valid, group-strint-pc, webcrypto, offices, w3f, mlw, group-wot-workshop-pc, team, webandtv-moderators, ab, group-share-psi, group-payment-workshop-pc, memberEditors, w[CUT]
Zakim joined the channel
# 16:55 Zakim ok, trackbot; I see T&S_SOCIG()1:00PM scheduled to start in 5 minutes
# 16:56 harry well, it's SOCWG but I suspect systeam just got it backwards
# 16:56 rhiaro should have an actual working connection this week
# 16:56 Arnaud hmm, I wonder whether this is going to mean we won't get the right tracker associated with the call
# 16:57 harry but I don't think Social IG has tracker set-up yet
# 16:57 harry anyways, poor systems team will get a quick request to disambiguate the two groups
# 16:57 Zakim the conference code is 7625 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), harry
# 16:58 harry just got back from vacation BTW, so I hope things went well last week
# 16:58 Zakim I don't understand 'who's on the phone', harry
# 16:58 Zakim I don't understand 'who is on the phone', harry
# 16:58 Zakim T&S_SOCIG()1:00PM has not yet started, Arnaud
# 16:58 Zakim On IRC I see harry, jtauber, elf-pavlik, jasnell, nicolagreco, cmhobbs, Shane, Morbus, bblfish, Tsyesika, bryan, mattl, tommorris, deiu, Arnaud, melvster, wilkie, Loqi, RRSAgent,
# 16:58 Zakim ... rhiaro, bret, aaronpk, kylewm, trackbot, botie, sandro, rektide, wseltzer, oshepherd
# 16:58 harry I assume you are on phone by yourself elf :)
# 16:59 Zakim T&S_SOCIG()1:00PM has not yet started, sandro
tantek joined the channel
# 16:59 Zakim sees on irc: harry, jtauber, elf-pavlik, jasnell, nicolagreco, cmhobbs, Shane, Morbus, bblfish, Tsyesika, bryan, mattl, tommorris, deiu, Arnaud, melvster, wilkie, Loqi, RRSAgent,
# 16:59 Zakim ... rhiaro, bret, aaronpk, kylewm, trackbot, botie, sandro, rektide, wseltzer, oshepherd
# 16:59 Loqi sandro: tantek left you a message on 8/24 at 3:38pm: next time you're around, come on over to #indiewebcamp on Freenode and let's chat IndieWebCamp Cambridge/MIT venue details with caseorganic!
# 17:00 Zakim the conference code is 7625 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), sandro
# 17:00 Zakim ok, sandro; that matches T&S_SOCIG()1:00PM
# 17:00 Zakim On the phone I see ??P0, [IPcaller], aaronpk, +1.559.707.aaaa, ??P8, Sandro, Hhalpin (muted), Arnaud, ??P9
# 17:01 Zakim sorry, tantek, I do not recognize a party named 'P12'
# 17:01 harry Note that due to complaints, we now have the call at 7:00 CET for Europeans. Otherwise it was 10:00 PM CET for Europeans
# 17:02 Zakim sandro, listening for 10 seconds I heard sound from the following: ??P0 (9%), Sandro (21%)
# 17:02 Shane Zakin, ??P13 is Shane
# 17:02 harry I'd just hold a sec, people are still dialing in
caseorganic joined the channel
# 17:03 Zakim tantek, listening for 10 seconds I heard sound from the following: Sandro (9%), Arnaud (41%)
# 17:03 caseorganic Hello - I'm on the call
# 17:03 Zakim harry, listening for 11 seconds I heard sound from the following: Arnaud (14%), +1.559.707.aaaa (32%)
# 17:03 Zakim harry, listening for 10 seconds I heard sound from the following: Sandro (100%), [IPcaller] (19%), [IPcaller.a] (5%)
# 17:04 Zakim sees on the phone: ??P0, jtauber, aaronpk, james (muted), Sandro, Hhalpin (muted), Arnaud, tantek, [IPcaller.a], ??P13, rhiaro (muted), deiu (muted), +44.783.406.aabb
# 17:04 nicolagreco how can I get into the call?
# 17:05 harry generally, you just type "Ircname: blah blah"
# 17:05 rhiaro Can people say their nicks when they speak please? Or I won't know
# 17:05 harry to continue past one line with same speaker, type "... blah bblah
# 17:05 Zakim sees on the phone: elf-pavlik (muted), jtauber, aaronpk, james (muted), Sandro, Hhalpin (muted), Arnaud, tantek, [IPcaller.a], ??P13, rhiaro (muted), deiu (muted), oshepherd
# 17:05 Shane I'm on the call but only able to half pay attention today
# 17:06 Zakim sees on the phone: elf-pavlik (muted), jtauber, aaronpk, james (muted), Sandro, Hhalpin (muted), Arnaud, tantek, tommorris, ??P13, rhiaro (muted), deiu (muted), oshepherd,
MattMarum and ShaneHudson joined the channel
# 17:07 Zakim On the phone I see elf-pavlik (muted), jtauber, aaronpk, james (muted), Sandro, Hhalpin (muted), Arnaud, tantek, tommorris, ??P13, rhiaro (muted), deiu (muted), oshepherd, bblfish,
# 17:11 harry due to my skype failing, I'm on a mobile phone BTW so I'll be a bit quiet
# 17:12 harry If anyone has questions about Invited Expert status, please ping me. It's possible we have missed a few applications, there was a bug in the set-up of the WG
# 17:13 rhiaro ... This is the first formal call. Non-members should join the WG
# 17:13 harry The only person I have in my queue is Markus from Hydra.
jasnell and caseorganic joined the channel
melvster1 joined the channel
# 17:14 rhiaro ... Sticking with Boston time through daylight savings
# 17:14 harry Re IE status caseorganic, we'll give you a 6 month IE is as standard for a possible W3C member.
# 17:15 rhiaro Arnaud: Tracking of actions and issues with the tracker
# 17:16 rhiaro ... We could use github issue tracker? Up to WG
# 17:16 aaronpk sandro: the w3c mediawiki blocks hotlinked images, so not unless that setting is changed
# 17:16 rhiaro ... Shouldn't split attention over too many different tools
# 17:16 tantek I think if a spec author wants to use github for their spec, and github issues for their spec issues, that should be ok.
# 17:16 rhiaro ... tracker allows creating and tracking states of issues; anyone can raise an issue
# 17:17 tantek However I'm ok with "Tracker" being the default for group-level administrivia etc. issues
# 17:17 rhiaro ... WG keeps an eye on raised issues, but isn't committed to dealing with them. Decide if they're important to tackle.
# 17:17 harry For the beginning of a WG I think tracker is fine for WG-level issues
# 17:17 harry for specs, folks tend to use github or bugzilla, but we don't have specs yet
# 17:18 rhiaro Arnaud: Advantage of using the tracker is the trackbot
# 17:18 rhiaro ... trackbot automatically assigns actions, and close issues etc
# 17:19 rhiaro tantek: specs and spec-specific issues should be on github, easier for spec editor
# 17:20 Zakim sees sandro, tommorris on the speaker queue
# 17:20 Zakim sees sandro, tommorris on the speaker queue
# 17:21 rhiaro tommorris: github allows closing of issues to issues themselves, to help with working out how spec evolved
# 17:22 rhiaro Arnaud: So smaller issues can be handled with github, major issues with w3c tracker as it's well integrated with other tools
# 17:22 tantek to be clear, I myself do not use github for spec editing (I prefer wiki), but I know others do (e.g. jasnell ) and I have seen github spec editors use github issues quite efficiently and nicely
# 17:22 tommorris and if one uses the wiki, using the wiki for issues is sensible.
# 17:22 harry I have an open action re the relationship between OWF CLAs and W3C RFF with Ian and Wendy Seltzer
# 17:23 Zakim sees on the phone: jtauber, aaronpk, Sandro, Hhalpin (muted), Arnaud, tantek, tommorris, ShaneHudson, rhiaro (muted), deiu (muted), oshepherd, bblfish, MattMarum
# 17:23 rhiaro jasnell had action to find out who contributed to AS 2.0 Spec. It's on the wiki
# 17:24 rhiaro jasnell: All material contributions made by people already in WG, so should be covered
# 17:25 Zakim harry, listening for 10 seconds I heard sound from the following: jasnell (78%), Arnaud (3%)
# 17:25 tantek harry I think that's in the background of jasnell
# 17:25 rhiaro jasnell: The one person listed as needing to fill out the form wasn't correct after all
# 17:25 rhiaro jasnell: If any more issues come up, will investigate
# 17:25 harry Just quick note - it *likely* clears up the IPR issue, but I want a quick check from Wendy.
# 17:26 rhiaro Arnaud: Close previously discussed action re: AS2.0 spec
# 17:26 rhiaro Arnaud: Action for all - associate yourself with ircpeople page
# 17:27 rhiaro tantek: We can close that now everyone has been reminded
# 17:27 rhiaro Arnaud: Action to send out invite for new meetings closed
nicolagreco joined the channel
# 17:29 aaronpk bblfish: usually people link to an image that's on their own site
# 17:29 rhiaro Arnaud: For those not familiar with w3c process, first step is to publish a public working draft of a deliverable. Can be changed.
# 17:30 harry we could make it a formal proposal but might not be necessary
# 17:30 harry and then we make the formal publication proposal the meeting before TPAC
# 17:31 Arnaud PROPOSED: Aim to publish ActivityStreams 2.0 FPWD by TPAC
# 17:32 deiu if you -1, then you MUST produce substantial arguments to defend your vote
# 17:33 Arnaud RESOLVED: Aim to publish ActivityStreams 2.0 FPWD by TPAC
# 17:33 ShaneHudson Is the conference code still 2625? I got thrown off the call and it won't let me back in
# 17:33 rhiaro Arnaud: Proposal to split spec into core parts and vocabularies
# 17:34 rhiaro jasnell: Split documents on github, can roll back
# 17:34 rhiaro ... In order to simplify core document. Feedback was it's too complex with too many optional parts
jasnell-github joined the channel
# 17:35 jasnell-github [w3c-socialwg-activitystreams] tommorris opened pull request #9: fixing tantek's name (master...patch-1) http://git.io/HCFAiw
# 17:35 tantek is it possible to implement one without the other?
# 17:35 rhiaro ... Take a look at the repo now and comment from there
# 17:35 rhiaro jasnell: Can implement basic AS functionality from core document
# 17:36 rhiaro ... Vocab document provides field names, but you don't *have* to use them
# 17:36 Arnaud PROPOSAL: Split document into two documents: core and vocab
# 17:37 sandro +0 sounds fine, but I haven't really thought about it
# 17:37 tantek +1 per deferring to editor's discretion at assessing community consensus on this
# 17:37 rhiaro Arnaud: If at some point someone thinks this doesn't make sense, we can undo it
# 17:38 Arnaud RESOLVED: Split document into two documents: core and vocab
# 17:38 Zakim the conference code is 7625 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), harry
# 17:38 rhiaro ... We can reconsider things. (But not just because you didn't get the result you want)
# 17:39 tantek fears that url / id / self discussion requires a lot of context, including context of the surrounding JSON, to understand
# 17:39 rhiaro jasnell: In AS 1.0, no formal notion of links. Media links. url property and other ways of linking to other content, but no defined model. Led to interop conflicts in different implementations. Some poeple used media links, iris, urls, inconsistently
# 17:40 rhiaro ... In 2.0 link values have been formalised to add consistency
# 17:40 rhiaro ... Creates redundancy in some field definitions; self, canonical, url
# 17:41 rhiaro ... url had a poorly defined definition in AS 1. Goal is simplification.
# 17:41 oshepherd I'll note that the problem with url in 1.0 is that it reuses the "url" name for different things in different places, sometimes in conflicting ways
# 17:41 rhiaro ... Current version of the spec on github has current thoughts
# 17:41 rhiaro ... Take a look at the spec, section on link resolution, and offer feedback.
# 17:42 tantek right, we already have a permalink for this issue, with existing discussion and history
# 17:43 tantek I propose any more commentary on it to the *existing* issue
# 17:43 rhiaro tantek: Already an open issue on github with existing discussion
# 17:44 harry I'd keep it in github if possible - duplication leads to errors.
# 17:44 ShaneHudson I agree with tantek, but I would have an issue on the tracker that points towards the existing Github issue
# 17:44 harry Which is what we have, so I guess we're OK :)
# 17:45 aaronpk can we just point to the issue on the wiki so people can find it from this group?
# 17:45 Zakim sees harry, jasnell, bblfish on the speaker queue
# 17:45 Zakim sees jasnell, bblfish on the speaker queue
# 17:45 tommorris on the issue there, I'd recommend that interested party post comments on the Github tracker
# 17:45 harry sorry, that was an old point about OWF CLA and RFF, a minor legal point
# 17:46 rhiaro jasnell: if you plan on submitting pull requests to the github repo, please list your github id on the wiki page
# 17:47 rhiaro bblfish: This type of issue - how to refer to something - there's a whole infrastructure to use already, with work on LDP and JSON-LD. So the solution could/should fit in nicely with everything else
# 17:47 rhiaro ... Use follow your nose. Things in JSON-LD and RDF.
# 17:48 tantek q+ to add to the discussion about working with existing tools and implementations
# 17:48 rhiaro Arnaud: In general, if people want to make suggestions on how to change the spec, write it down. Email or put it on the wiki, as a proposal for discussion on a call.
# 17:48 Zakim tantek, you wanted to add to the discussion about working with existing tools and implementations
# 17:49 rhiaro tantek: Agrees with bblfish about looking at existing implementations and tools. There's a broad variety. Incluidng indiewebcamp, where many people are publishing permalinks, using a url field
# 17:50 rhiaro ... draw from other sources of work, for interoperatbility.
# 17:50 rhiaro ... but not insisting on compatibility with anything in particular, as there are a *lot* of things.
# 17:50 bblfish yes, but that sounds like a way to make basic issues a constant point of discussion
# 17:50 jasnell Suggestion: use wiki to document change proposals and submit pull requests with specific spec changes. Every pull request that is not editorial would be raised as an issue
# 17:50 rhiaro Arnaud: the IG is chartered to do exploration work and figure out use cases and requirements for social web in general.
# 17:51 rhiaro ... WG has to develop specs to address use cases and requirements. WG scope is smaller than what the IG tackles. How will we handle this?
# 17:51 rhiaro ... Currently one page under the WG on the wiki. Who is this really owned by? IG refer to it from their wiki page.
# 17:52 rhiaro ... Have a free-for-all phase where people add their own use cases. Then go through an approval phase to choose what to tackle.
# 17:52 harry I'm not sure how that works out in W3C ACL space
# 17:52 harry but we can make a wiki anyone with a W3C account can edit
# 17:53 harry so that should not be a huge problem if people want the use-cases in that shared space.
# 17:53 rhiaro jasnell: From IG call last week; focus was to organise into task groups. One focused on use cases; architecture; vocabulary; lisaon with other groups, including this WG
# 17:54 rhiaro Arnaud: The IG don't have time constraints. They can come up with any use cases and write them down. WG can't tackle all use cases.
# 17:56 rhiaro tommorris: Prioritise use cases that are actually used on the web. Seems possible to work around real use cases rather than hypothetical ones.
# 17:56 tantek +1 tommorris: use-cases actively *in use* on the web should be prioritized
# 17:56 jasnell Question: can deciding on specific use cases to address be out on the agenda for the tpac meeting?
# 17:56 jasnell Gives time between now and then to document and discuss
# 17:57 tantek social web - assumes you want to be *social*, and do so *on the web* :)
# 17:57 rhiaro bblfish: What is the group trying to achieve? Framework for being able to discuss distributed relations between people. Decentralised communication/control. These are basic requirements.
# 17:57 rhiaro ... so social networks are a basic requirement
# 17:58 rhiaro tantek: We have the charter. We don't need to reason from the name of the group. Focus on the charter.
hhalpin joined the channel
# 17:59 bblfish User control of personal data: Some users would like to have autonomous control over their own social data, and share their data selectively across various systems. For an example (based on the IndieWeb initiative), a user could host their own blog and use federated status updates to both push and pull their social information across a number of different social networking sites.
# 17:59 rhiaro ... Decide what we're working on based on items in the charter.
# 17:59 hhalpin apologies, internet dropped - calling back in but still on shaky mobile connection.
# 17:59 hhalpin Zakim, what's the code?
# 17:59 Zakim the conference code is 7625 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), hhalpin
# 18:00 rhiaro Arnaud: We can continue this discussion next week
# 18:00 tantek thanks bblfish - yes, referencing the charter is my request rather than use of the name of the wg
# 18:00 rhiaro ... Important to have use cases as background
# 18:00 hhalpin Zakim, IPcaller is hhalpin
# 18:00 hhalpin trackbot, meeting adjourned
# 18:01 hhalpin trackbot, end meeting
# 18:01 Zakim As of this point the attendees have been Sandro, aaronpk, +1.559.707.aaaa, Hhalpin, Arnaud, tantek, +44.783.406.aabb, deiu, rhiaro, jtauber, oshepherd, elf-pavlik, tommorris,
# 18:01 Zakim ... bblfish, MattMarum, ShaneHudson, jasnell, bret, wilkie
caseorganic and caseorga_ joined the channel
# 18:07 Zakim Attendees were Sandro, aaronpk, +1.559.707.aaaa, Hhalpin, Arnaud, tantek, +44.783.406.aabb, deiu, rhiaro, jtauber, oshepherd, elf-pavlik, tommorris, bblfish, MattMarum,
deiu, jasnell_ and jasnell-github joined the channel
# 18:25 jasnell-github [w3c-socialwg-activitystreams] jasnell closed pull request #9: fixing tantek's name (master...patch-1) http://git.io/HCFAiw
# 18:27 jasnell :-) ... one the the worst things about publishing documents using the IETF process is the lack of an extended charset to work with. I'm much happier to be publishing in HTML now
# 18:28 tommorris HTML is a pretty neat format. I think it might catch on one day.
# 18:28 oshepherd I do like ReSpec. I sometimes wish it had a better "This is just a thing I'm writing" mode, you know, without a breat big "unofficial spec" banner down the side
# 18:29 tantek oshepherd: ReSpec is the one that requires clientside JS right?
# 18:29 oshepherd Wouldn't the correct thing to do be to register these things with the IETF registry if they're actually used?
# 18:29 tantek oshepherd: nope, because see above, IETF process lol
# 18:29 oshepherd tantek: Yes, but you can then spit out a static HTML file
# 18:29 jasnell AS2 does not depend directly on the IANA Link Registry... it includes a normative reference to RFC 5988 which provides the formal definition of a "Link Relation" and just also happens to establish the IANA registry. But a link relation can be a proper link rel without ever being registered with IANA
# 18:29 tantek that's why BOTH HTMLWG and WHATWG decided to ditch IETF registry
# 18:30 tantek jasnell - good at least avoiding any dependency is good
# 18:30 jasnell having registered several link relations via the IETF process, it's actually not that difficult
# 18:30 oshepherd My issue with the microformats wiki is that a wiki is hardly a registry :-)
# 18:30 tantek jasnell - it is more difficult (and less accurate) over time than the microformats rel-registry
# 18:31 tantek oshepherd: two distinct orgs disagree with you
# 18:31 jasnell as long as it's a valid link rel, I don't particular care where it's documented
# 18:32 tantek jasnell - the issue is when the defintion of "valid link rel" depends on it being registered
# 18:33 tommorris "a wiki is hardly a registry" - next you'll say it isn't a valid encyclopaedia. ;-)
# 18:34 oshepherd tommorris: In general, I'd like to see these things hashed out through a minimally rigorous process :-)
# 18:35 tantek oshepherd: problem with that methodology is when "minimally rigorous process" trumps actual use, and process (or patience with ceremony, filing out forms etc.) takes over. which is what happened with IANA.
# 18:35 tommorris Me and Tantek hitting people with sticks if they post stupid shit is a perfectly good process. ;)
# 18:36 jasnell there are advantages and disadvantages to the IETF/IANA approach. One advantage is that the references and documents are stable. One disadvantage is that it's slow as hell, especially if you take the WG approach
# 18:37 jasnell typically avoids the IETF WG approach because he's not a sadist
# 18:39 jasnell tantek: the definition of "valid link rel" has nothing to do with whether it's registered with IANA or not
# 18:43 jasnell Well, some specific specs might have that requirement, but AS2 does not. That's the spec I'm concerned with. AS2 requires only that they be valid Link Rels, it does not require that they are registered with IANA. That ought to be good enough. That definition ought to easily cover everything in the microformats-wiki also
# 18:44 tantek jasnell - then AS2 has it's own defintion of "valid" for "valid link rel"?
# 18:44 tantek because in HTML LS and HTML5, "valid link rel" is defined to mean in the spec, or in the registry.
# 18:44 tantek which is new from HTML4.x - where any author could use simple strings for link rels (valid by syntax)
# 18:45 jasnell RFC5988 defines a syntax for link relations and defines two classes. It says well known link relations *can* be registered, not that they MUST
# 18:46 jasnell the implication is that non-URI form link relations ought to be registered, yes, but it's perfectly fine if they're not
# 18:47 tantek note that HTML does not reference nor care about rfc5988
# 18:47 jasnell if the language in the AS2 draft needs to be clarified to make that clear, then I can update it
# 18:48 tantek and defines its own proper syntax for relation type (rel values)
# 18:48 tantek just putting that out there, as the most common use of link relations, "rel" has *nothing* to do with rfc5988
# 18:49 oshepherd Though I suppose it would be equally valid to defer to that section of HTML5 (since we are in the W3C camp here)
# 18:50 tantek that would be my recommendation. rather than drag back all the old IETF arguments.
# 18:50 oshepherd Really though I think it would be preferable if the link relations moved back into a "links" array :-)
# 18:50 tantek in practice I hope we don't find any breaking differences.
# 18:50 jasnell tantek: does the HTML syntax differ from the RFC5988 syntax in any particular way? Is there a reason NOT to point at RFC5988 other than the fact that HTML5 doesn't?
# 18:51 jasnell not really enough of a justification. there should be a technical justification, not a preferential one
# 18:52 oshepherd In absence of a technical justification, would linking to a speficiation from the standards body not have a nominal preference?
# 18:53 tantek jasnell - where registries are concerned, less process, more comprehensive, more up to date, are all important considerations.
# 18:54 tantek (and among those that made HTMLWG et al drop IANA for rel)
# 18:54 jasnell the technical justification for pointing to RFC5988 is two-fold: (1) 5988 defines a constrained, verifiable syntax for link relation values (see section 5) and (2) there's a clear connection to other places RFC5988 link relations are used... such as the HTTP Link Header
# 18:55 tantek jasnell - (1) HTML5 defines a constrained, verifiable syntax for link relation values, and (2) AS are a *format* more like HTML5, than a *protocol* (HTTP)
# 18:55 oshepherd the technical justification for pointing to HTML5 is two-fold: (1) HTML5 defines a constrained, verifiable syntax for link relation values (see section 5) and (2) there's a clear connection to other places link relations are used... such as the HTML Link element
# 18:56 jasnell lol.. but neither of you have answered the question: Why is linking to the RFC 5988 definition bad? Is it somehow incompatible with the HTML5 definition?
# 18:57 jasnell are HTML link relations not usable in 5988 implementations?
# 18:57 tantek jasnell - because 5988 is now irrelevant to the majority use of link relations that's why
# 18:58 tantek linking directly to HTML5 defn of link relations makes more sense than an obsolete IETF draft that *might* be equivalent
# 18:59 jasnell I would agree that many of the registered link relations themselves may be out of sync with common use
# 18:59 tantek jasnell - in practice what's happening is that link relation is happening at the HTML level first, getting documented in the registry, and then getting extended to HTTP
# 19:00 tantek no one is bother with IANA ceremony for new stuff
# 19:00 tantek jasnell - 5988 is obsolete because more and more innovation in link relations is completely ignoring it.
# 19:01 tantek it may work as a historical document, but certainly not worth normatively citing in any future specs
# 19:03 tantek normatively referencing 5988 implies IANA ceremony even if it doesn't require it.
# 19:04 tantek and at this point, implementers are reading/coding to HTML5 (or WHATWG HTML LS), rather than 5988
# 19:09 jasnell will have to agree to disagree on that point. linking to RFC5988 does not require IANA registration in any way. By way of analogy, I can write a spec defining a new HTTP header that normatively references the HTTP spec without ever saying anything about the IANA HTTP Header Registry...
# 19:10 oshepherd RFC5988 defines the IANA registry as the canonical source of defined relations
# 19:17 oshepherd The definition of rel per HTML5 is broadly compatible with RFC5988, but WhatWG doesn't recognize URIs
# 19:18 jasnell "RFC5988 states that well known link relations *can* be registered "for convenience and/or to promote reuse". 5988 says nothing about the registry being the canonical source of anything. The spec does give specific guidelines for registered link relations but it does not say or even imply that all link relations must be registered. It doesn't even come close to doing so. Use of the IANA registry is optional. Which brings us back to the original
# 19:18 jasnell point: The AS2 spec does not require the use of registered link relations. I have no problem mentioning the HTML5 definition of link rels in AS2, but I still see no technical reason why we cannot reference the RFC5988 definition of Link Relations.
# 19:24 jasnell question question: where is the syntax for "space-separated tokens" formally defined in HTML5? looking for the link
# 19:27 jasnell so in HTML, a valid link relation is any string that doesn't contain a space char or a comma. So the only difference between that an RFC5988 link rel is that commas are allowed in the 5988 URI/IRI form.
bblfish, deiu and ShaneHudson joined the channel
# 20:15 jasnell tantek: ok, so looking it over... here's a possible compromise on the link rel issue...
# 20:16 jasnell 1. the spec will clarify that "valid link rel" means valid in terms of the relation-type rule in RFC5988, and that link relations do not need to be registered to be valid
# 20:17 jasnell 2. the spec will call out that HTML5 has a definition of link rel that differs somewhat from the RFC 5988 definition
# 20:17 jasnell 3. the spec will say that, for the sake of interoperability, link rels used in AS2 SHOULD be compatible with both definitions.
bblfish joined the channel
# 20:26 Zakim excuses himself; his presence no longer seems to be needed
bblfish joined the channel
# 20:35 jasnell looking over the two definitions, there is at least one very good technical reason to favor the 5988 link rel definition: all 5988 link rels are also valid JSON members without requiring escaping
# 20:36 jasnell for instance, the string "foo" (with the quotes) actually appears to be a valid rel value according to HTML5
# 20:38 tantek jasnell - I'd doubt that since rel values in HTML have to be able to inside rel=""
# 20:38 jasnell I'm going off the definition given in the draft I'm seeing
# 20:39 jasnell "A set of space-separated tokens is a string containing zero or more words (known as tokens) separated by one or more space characters, where words consist of any string of one or more characters, none of which are space characters."
# 20:39 tantek though you can try to mockup an HTML document with such a quoted rel value and try the HTML validator to check if you believe otherwise
# 20:39 jasnell how implementations actually work vs. what the spec actually says are typically two different things
# 20:39 tantek jasnell - it's a way of testing your assumption and then potentially altering the spec if it was unclear
# 20:40 jasnell when used in markup, it would end up as rel=""rel""... which would be valid according to the spec
jasnell_ joined the channel
# 20:43 jasnell_ 5988 takes a stricter approach... limiting link rel to specifically (LOALPHA *( LOALPHA | DIGIT | "." | "-" )) | URI
# 20:45 jasnell_ which makes far more sense. given that, I think the above compromise makes the most sense
jasnell, nicolagreco and bblfish joined the channel