#Loqisandro: 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!
#elf-pavliknow hears sombe beep boop and someone typing :)
#harryIf 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
#rhiaro... This is the first formal call. Non-members should join the WG
#harryThe only person I have in my queue is Markus from Hydra.
#rhiarotommorris: github allows closing of issues to issues themselves, to help with working out how spec evolved
#rhiaroArnaud: So smaller issues can be handled with github, major issues with w3c tracker as it's well integrated with other tools
#tantekto 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
#tommorrisand if one uses the wiki, using the wiki for issues is sensible.
#harryI have an open action re the relationship between OWF CLAs and W3C RFF with Ian and Wendy Seltzer
#rhiarojasnell: 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
#rhiaro... In 2.0 link values have been formalised to add consistency
#oshepherdI'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
#rhiaro... Current version of the spec on github has current thoughts
#rhiarobblfish: 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
#rhiaro... Use follow your nose. Things in JSON-LD and RDF.
#tantekq+ to add to the discussion about working with existing tools and implementations
#tommorrisLDP for those who do't know is Linked Data Platform
#rhiaroArnaud: 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.
#rhiarotantek: 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
#rhiaro... draw from other sources of work, for interoperatbility.
#rhiaro... but not insisting on compatibility with anything in particular, as there are a *lot* of things.
#bblfishyes, but that sounds like a way to make basic issues a constant point of discussion
#jasnellSuggestion: 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
#rhiaroArnaud: the IG is chartered to do exploration work and figure out use cases and requirements for social web in general.
#rhiarojasnell: 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
#jasnellGives time between now and then to document and discuss
#tanteksocial web - assumes you want to be *social*, and do so *on the web* :)
#rhiarobblfish: What is the group trying to achieve? Framework for being able to discuss distributed relations between people. Decentralised communication/control. These are basic requirements.
#rhiaro... so social networks are a basic requirement
#rhiarotantek: We have the charter. We don't need to reason from the name of the group. Focus on the charter.
hhalpin joined the channel
#bblfishUser 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.
#rhiaro... Decide what we're working on based on items in the charter.
#ZakimAs 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,
#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
#tommorrisHTML is a pretty neat format. I think it might catch on one day.
#oshepherdI 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
#tantekoshepherd: ReSpec is the one that requires clientside JS right?
#oshepherdWouldn't the correct thing to do be to register these things with the IETF registry if they're actually used?
#tantekoshepherd: nope, because see above, IETF process lol
#oshepherdtantek: Yes, but you can then spit out a static HTML file
#jasnellAS2 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
#tantekthat's why BOTH HTMLWG and WHATWG decided to ditch IETF registry
#tantekjasnell - good at least avoiding any dependency is good
#jasnellhaving registered several link relations via the IETF process, it's actually not that difficult
#oshepherdMy issue with the microformats wiki is that a wiki is hardly a registry :-)
#tantekjasnell - it is more difficult (and less accurate) over time than the microformats rel-registry
#jasnellas long as it's a valid link rel, I don't particular care where it's documented
#tantekjasnell - the issue is when the defintion of "valid link rel" depends on it being registered
#tommorris"a wiki is hardly a registry" - next you'll say it isn't a valid encyclopaedia. ;-)
#oshepherdtommorris: In general, I'd like to see these things hashed out through a minimally rigorous process :-)
#tantekoshepherd: 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.
#tommorrisMe and Tantek hitting people with sticks if they post stupid shit is a perfectly good process. ;)
#jasnellthere 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
#jasnelltypically avoids the IETF WG approach because he's not a sadist
#jasnelltantek: the definition of "valid link rel" has nothing to do with whether it's registered with IANA or not
#jasnellWell, 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
#tantekjasnell - then AS2 has it's own defintion of "valid" for "valid link rel"?
#tantekbecause in HTML LS and HTML5, "valid link rel" is defined to mean in the spec, or in the registry.
#tanteknote that HTML does not reference nor care about rfc5988
#jasnellif the language in the AS2 draft needs to be clarified to make that clear, then I can update it
#tantekand defines its own proper syntax for relation type (rel values)
#tantekjust putting that out there, as the most common use of link relations, "rel" has *nothing* to do with rfc5988
#oshepherdIs the HTML definition actually any different?
#oshepherdThough I suppose it would be equally valid to defer to that section of HTML5 (since we are in the W3C camp here)
#tantekthat would be my recommendation. rather than drag back all the old IETF arguments.
#oshepherdReally though I think it would be preferable if the link relations moved back into a "links" array :-)
#tantekin practice I hope we don't find any breaking differences.
#jasnelltantek: 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?
#jasnellnot really enough of a justification. there should be a technical justification, not a preferential one
#oshepherdIn absence of a technical justification, would linking to a speficiation from the standards body not have a nominal preference?
#tantekjasnell - where registries are concerned, less process, more comprehensive, more up to date, are all important considerations.
#tantek(and among those that made HTMLWG et al drop IANA for rel)
#jasnellthe 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
#tantekjasnell - (1) HTML5 defines a constrained, verifiable syntax for link relation values, and (2) AS are a *format* more like HTML5, than a *protocol* (HTTP)
#oshepherdthe 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
#jasnelllol.. 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?
#tantekjasnell - 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
#tantekno one is bother with IANA ceremony for new stuff
#tanteknormatively referencing 5988 implies IANA ceremony even if it doesn't require it.
#tantekand at this point, implementers are reading/coding to HTML5 (or WHATWG HTML LS), rather than 5988
#jasnellwill 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...
#oshepherdRFC5988 defines the IANA registry as the canonical source of defined relations
#oshepherdThe definition of rel per HTML5 is broadly compatible with RFC5988, but WhatWG doesn't recognize URIs
#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
#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.
#jasnellquestion question: where is the syntax for "space-separated tokens" formally defined in HTML5? looking for the link
#jasnellso 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
#jasnelltantek: ok, so looking it over... here's a possible compromise on the link rel issue...
#jasnell1. 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
#jasnell2. the spec will call out that HTML5 has a definition of link rel that differs somewhat from the RFC 5988 definition
#jasnell3. the spec will say that, for the sake of interoperability, link rels used in AS2 SHOULD be compatible with both definitions.
#Zakimexcuses himself; his presence no longer seems to be needed
bblfish joined the channel
#jasnelllooking 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
#jasnellfor instance, the string "foo" (with the quotes) actually appears to be a valid rel value according to HTML5
#tantekjasnell - I'd doubt that since rel values in HTML have to be able to inside rel=""
#jasnellI'm going off the definition given in the draft I'm seeing
#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."
#tantekthough 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
#jasnellhow implementations actually work vs. what the spec actually says are typically two different things
#tantekjasnell - it's a way of testing your assumption and then potentially altering the spec if it was unclear