Meeting minutes
<gibsonf1> I can attempt to scribe
Introductions and announcements
laurens: no announcements
Relationship between Protocol and UC&R document
laurens: jeswr and ebremer are starting work on protocol deliverable
… ucr WG note work is ongoing
… both deliverables need to keep up momentum
… ucr is essential for distilling requirements
… also allows us room for prioritization and scope discussions
… protocol doc has interplay in other direction in showing what the protocol may look like
… at this stage, both are living documents
<laurens> acoburn: As we begin discussing the details of the protocol, we'll have to have scoping discussions and prioritization conversations which should be informed by the UC&R document
<laurens> ... in an ideal scenario the UC&R would be complete, however the timeline doesn't afford us that flexibility
<laurens> ... so we'll have to move both forward, realizing that is not ideal.
<Zakim> uvdsl, you wanted to say UCs have not yet been reviewed wrt to scope of the protocol according to the charter (as far as I see)
uvdsl: yes, we should discuss use cases, emphasizing that we haven't yet seen which are in scope
laurens: the scoping discussion has not yet been had
… the scope discussion will be easier once we have a clearer sense of the overall ucr document
pchampin: to complement, the coverage/refinement of UCRs is one criteria
… the other requirement is the charter
laurens: is the publication process moving forward?
pchampin: hadrian had a change of affiliation, and we cannot publish right now, will be sorted this week
Discussion: Resource identifiers
<uvdsl> w3c/
<gb> Issue 28 Resource Identification (by uvdsl)
laurens: there has been some discussion related in the protocol repository
… the editors would like to begin drafting some text
… one of the first and foundational item is that identifiers should be globally unique
… iri vs uri can be discussed later on
<gibsonf1> +1
laurens: seems we are mostly in consensus, but would like to hear thoughts
uvdsl: does the group want uri/iri ?
laurens: I don't want to start there, would like to start with whether the identifiers are globally unique
<dmitriz> what do you mean by 'atomic'?
laurens: by atomic, I mean that it can be completely identified in a single string
<Zakim> gibsonf, you wanted to say in addition to global unique, reachable via webn
laurens: unlike in SOAP where multiple elements (tuple) is needed
gibsonf: agree about globally unique, also reachable
ericP: is that the distinction between locator and identifiers?
uvdsl: for me I agree with gibsonf, that they are specifically using HTTP URIs (from charter docs)
… in SOAP, there is a tuple of identifier and operation
jackson: would like to push back on HTTP uris
… the current Solid CG Report requires HTTP URIs and it is hard to be compatible with DID
… limiting to HTTP URIs is very limiting
<dmitriz> what's the motivation for limiting the protocols, out of curiosity?
<gb> Issue 24 Reasons for separate rest bindings (by jeswr)
jackson: perhaps a provision in the specification to allow for certain protocols
tallted: pretty much in favor of the first part (global uniqueness)
… I question atomicity: there may be fragment identifiers
… relatedly, one goal of LWS is that a user can choose to move between providers
… if we limit to HTTP URIs, that requires additional infrastructure to not break links
… some providers allow vanity domains, but not all, esp financial institutions
<Zakim> uvdsl, you wanted to point to the bindings decision w3c/
uvdsl: this comes back to issue #24 related to bindings
<gb> Issue 24 Reasons for separate rest bindings (by jeswr)
uvdsl: i.e. whether to have binding or to tightly couple with HTTP
… limiting to HTTP URIs is restricting, it makes sense to limit to the transfer protocol. That doesn't limit to HTTP URIs
… there are DID methods that allow for HTTP transfer protocol
<Zakim> gibsonf, you wanted to say are we limiting representations to documents (re TallTed)
gibsonf: related to the document, we are not limiting a resource to a document
… I hope that is not the only thing to expect as a representation
<Zakim> dmitriz, you wanted to ask _why_ we're limiting protocols
dmitriz: why are we limiting URL protocols?
… what does that buy us
<Zakim> TallTed, you wanted to mention DID "universal resolver"
dmitriz: what problem does it solve?
tallted: there was also a concern raised about resolving DID methods for arbitrary methods
… the expectations from the DID WG that there will be libraries with global resolvers
… i.e. "resolve this did" and the client receives whatever the identifier references
<Zakim> uvdsl, you wanted to counterask
uvdsl: my perspective is that the specification should give implementers clear guidance
<gibsonf1> +1 to uvdsl
uvdsl: and without that guidance, we defeat the purpose of the spec
<dmitriz> that doesn't make any sense. do we also want to constrain the _packets_ to TCP only?
jackson: as an implementer, I'd want to make it easy, but I'd want a specific group to implement
laurens: we need to produce a test suite, and it needs to be testable
… any restriction needs to serve a purpose
… e.g. identifiers that are also locators
… I want a concrete requirement for that restriction
dmitriz: we are not going to constrain to TCP or how packets resovle over the wire
… we should say URLs and not specify the retrieval mechanism
<TallTed> +1 this may be premature restriction
ryey: I second dmitriz's perspective
… specifying URIs would be fine
… for the issue of portability, there are ways to approach this with relative URLs
… or a special header for where to resolve
… in the end there isn't a real issue for how the resource is identified
pchampin: I sypathize with dmitri's argument, that we want to rely on existing things that are specified elsewhere
… however, URIs are very abstract
… and we may want to characterize the properties of the URIs that we use
… e.g. resolvability
jackson: I don't think we should restrict only on HTTP
… if I am a client library, and someone has included a link to some location with a weird protocol
… e.g. if we say that we support 3 protocols and therefore all client libraries need to support all
<Zakim> uvdsl, you wanted to counter-argument flexibility should only be written into the spec if there are use cases
jackson: spec should have a mechanism to say these are the required protocols and here's how to expand
uvdsl: I agree about restricting to a list, I don't like a registry because it is too open
… I would push back on notion that we need to accommodate flexibility
… flexibility should only be part of the spec based on use cases, as outlined by the charter
… that will raise questions down the line
<Zakim> acoburn, you wanted to mention did and vc input documents
<dmitriz> text should be added to the spec only if it's solving a problem. restricting to http URLs is not solving any problem that was identified...
<laurens> acoburn: As I recall we have both the DID WG and VC WG and the documents they produce as inputs to our work
<laurens> ... that is part of the scope.
uvdsl: did and vc groups are to be aligned but they are not normatively listed as input documents
… arguing to be careful about what we write into the spec
<pchampin> uvdsl, I agree that we must not aim at flexibility for the sake of it; but I do believe that the flexibility discussed here (esp. for portability) is backed by use-cases
<uvdsl> pchampin, sure! Looking forward to seeing these use cases :)
laurens: vc and did documents are w3c recommendations and should be included in our consideration
… and some level of interop
<dmitriz> the burden of proof should be on why add restrictions in the first place.
ryey: a few weeks ago, the DID resolver WG was being created. Is DID resolution already a thing?
<Zakim> pchampin, you wanted to respond to ryey
<uvdsl> dmitriz, I disagree with that statement
pchampin: did resolution is not currently a recommendation
… it is a work item on the REC track
… so eventually would be a REC
ryey: are there rules of thumb for working with other W3C draft documents?
laurens: we have discussed this related to input documents
pchampin: we cannot have normative dependencies on doc that are much less mature
… we are allowed one level of difference
… we are currently behind did resolution
… unless they have problems, we shouldn't have an issue there
dmitriz: each did method has a definition for how a did is resolved
… still very strongly against restricting URI protocols
… imagine restricting to only HTTP but then HTTPS comes
… one example: this exact question is a problem in the VC community
… there is a spec for OpenID federation for issuer registries
… that specs restricts to HTTPS, trying to exclude DIDs
… all that ended up happening is that the VC group read the spec
… and either had to ignore spec restriction or fork the spec
laurens: I want to second that
… there are maintainability issues with too much restrictions without clear use cases
uvdsl: for updating the scheme of the URI, why not open up a version 2?
… the discussion in CG is very different
… I don't think the arguments presented would convince the community group
laurens: this is a discussion that could be made broader, but this needs to be clarified in this WG
… also reinstating a working group is not simple
jackson: I have an open mind, but I'd like more clarification
… if we have a specification with open URIs that include links using a random URI scheme
… and the technology encounters that, then a client library won't know how to resolve that
… what should happen to client libraries
dmitriz: the answer is always: "throw an error"
<uvdsl> so much for interoperability
dmitriz: i.e. what happens if you try to fetch a URL over HTTP and there is a network issue or server error
… but the principle is the same
<Zakim> acoburn, you wanted to note also that OpenID Federation is not W3C
<laurens> acoburn: OpenID and W3C are different governance bodies
<laurens> ... when crossing boundaries this isn't as straightforward
jackson: re: "throw an error", if there is a network error, the error handling is already baked in
… there should be a base level where every client library needs to implement
<dmitriz> sure, "at least implement HTTP" seems reasonable as a requirement.
jackson: would your proposal be "at least implement these protocols"?
… or that we shouldn't even mention http/did in the specification
uvdsl: re "throw an error" flies in the face of the solid charter
… this makes interoperability challenging
<dmitriz> @uvdsl -- part of our charter is to define error conditions.
<gb> @uvdsl
uvdsl: you can have spec compliant systems that don't interoperate
<Zakim> ericP, you wanted to describe requirements (MUST impelement) in terms of branding
uvdsl: I don't think this aligns with the goals of the charter
ericP: we should describe the optional and required protocols as "branding"
<uvdsl> sure, so you suggest prioritising error conditions over interoperability?
ericP: if someone goes to one place to get a server and elsewhere to get a client, there is a desire that they talk to each other
<dmitriz> I'm suggesting that restricting url protocols does not buy you interoperability. all that it buys you is -- either the spec gets forked, or implementers will just ignore it.
ericP: the "box" could be lws+did
<uvdsl> dmitriz, so you say that agreeing on a transport protocol does not induce interoperability? That is an interesting take.
<dmitriz> this is not hypothetical, either -- this JUST happened with open id federation.
ericP: if someone creates a resource with HTTP and then performs a GET over SPARQL, you want to be able to say that the resource is the same
<dmitriz> @uvdsl - we're not talking about transport protocol though, notice. we're not talking about TCP or UDP. which is my point.
<gb> @uvdsl
<dmitriz> we're talking about unnecessary URL protocol restriction.
jackson: that seems acceptable: a few requirements, but don't invalidate other implementations that use others
<uvdsl> Yeah, we were talking about HTTP. And agreeing on HTTP does not induce interoperability?
laurens: we need to be mindful of layering of future applications/domains on top of LWS
<uvdsl> You are right, HTTP is of course not transport.
<laurens> PROPOSAL: Protocol document to include HTTP resource identifiers despite not yet having been formalized as a requirement in the Use Cases & Requirements WG Note.
laurens: there was a discussion to use HTTP URIs in the protocol document
<ericP> +1
<eBremer> +1
<laurens> +1
<acoburn> +1
<TallTed> +1
<bendm> +1
<jeswr> +1
<gibsonf1> +1
<dmitriz> +1
<uvdsl> +1
<pchampin> +1
<RazaN> +1
<jackson> +1
<ryey> +1
RESOLUTION: Protocol document to include HTTP resource identifiers despite not yet having been formalized as a requirement in the Use Cases & Requirements WG Note.
<uvdsl> w3c/
<gb> Issue 28 Resource Identification (by uvdsl)
uvdsl: having arguments in writing and being able to discuss async would be appreciated
laurens: yes, we very much encourage that
<pchampin> uvdsl, I will add a pointer to the minutes of the discussions we just had in issue 28
hadrian: applied for IE status, began re-working some UCR docs
<uvdsl> Okay, thank you pchampin !
<Monsecom> Thanks!
<gibsonf1> +1