idServers - are they servers? authorities? what expectations do we have for them?

[jonathanrobie]

The name idServer implies some kind of server that offers functionality we have not defined. If these servers exist, what do we expect them to do, and how would someone with a Scripture Burrito use them?

Can a client running on a desktop or a smartphone create identifiers that a particular system understands? I think using URLs to identify naming authorities is the best approach, I am not questioning that, but I think the interchange formats we create should say as little as possible about systems, requiring as little as possible to exchange data.

Many identification schemes that associate a prefix with a URL do not require a particular set of servers or any particular kind of software, they use the URL merely to identify the authority that owns the naming scheme.

I suspect we could simplify this and make it clearer by doing the following:

• Change the name so that it does not imply that a server needs to exist in order to have a naming authority.
• Remove statements that say that Scripture Burrito assumes the existence of "identity servers".

[smorrison]

Would it be enough to rename the section to 'authority'? Maybe have URL as an optional element in the element?

[jag3773]

Let's change this to idAuthority every where it shows up in the spec.

[jtauber]

Should it be idAuthority or plural idAuthorities (given it's currently plural idServers?

[jag3773]

Plural, since we are still maintaining it as a list.

[jtauber]

I'm also changing idServer under identification to idAuthority.

There is, however, also a idServerKey that sometimes appears under (what is now) idAuthorities.

[jtauber]

I'm also presuming I shouldn't change anything under proto_doc

[jag3773]

Related to #227

[jag3773]

Several different entangled ideas:

• Location
• Naming
• Ownership - should not be construed with this field, the Agency section is for this.

Should the id and idAuthority be deference-able ?

[jtauber]

To me the fundamental purpose seems to be Naming, i.e. to be able to say: "authority X calls this burrito Y (version Z)"

We all agree that Ownership is not what this is for.

I still don't understand the purpose of the Location purpose. You have the burrito so you don't know need to know where to get it. What are the actual reasons for needing a location? To check if there are more up-to-date versions?

Note that I think there is a distinction between a deferenceable burrito and requiring that the authority information includes a link to the authority (or even to information from the authority on the naming system used).

[jonathanrobie]

Suppose I have a Kindle book and I know the Amazon identifier. I know that Amazon is the authority that created the identifier but I do not yet know the location, I need to know Amazon's APIs or URI conventions before I can dereference it. So I think the primary purpose is identification.

I think that's about right. If a resource is available online, an authority could create a URI template so that a client can construct a URL that can be used to fine the resource. That template provides optional location.

[smorrison]

URLs explicitly about location, URNs are explicitly not, URIs encompass both.

Why not URNs? e.g. urn:sb:ptx::?

[jag3773]

Agreed that the purpose of this field is only naming–machine readable ids, in a technical sense.

[jtauber]

I've started discussions:

232

233

235

So perhaps we can close this issue.

[jtauber]

or alternatively, we keep this open and take it to mean "James to update documentation based on discussions"

[jtauber]

Once #246 and #232 are agreed on, I'll update documentation and can close this.

[jtauber]

as we have #216 to track the updates from #246 and #232, I'm closing this.