Re: making the webcredits.org spec more strict about 'source' and 'destination' fields.

On 17 April 2012 22:51, David Nicol <davidnicol@gmail.com> wrote:

>
>
> let's work out the best way we can explain things well to a wide audience
>>
>>
>>> - if it's the URL of an interface, e.g. mailto:user@host, then it
>>> should be a way to contact the source/destination agent of the IOU.
>>>
>>
>> in the case of mailto this makes sense ... ive not considered very
>> possible uri scheme at this point ... it's probably quite an advanced use
>> case, but it's will be great if we can flesh it out as so many people use
>> email today
>>
>> tel: and xmpp: are are other interesting schemes where this applies
>>
>
> I got the impression from looking at webcredits several drafts ago that
> exactly what the source and destination identity-strings were was still
> something up in the air. Punting that (possibly open) enumeration to an
> external spec is entirely appropriate, but which one? The "strong open"
> position would be, they can be any strings of characters that is understood
> by all involved in a particular use instance. More restricted positions
> start with length limits, then recommending (but not mandating, at the
> protocol specification level) particular schemes.
>
> An accurate specification conformance statement, conformant to a
> strong-open position, advertised by a service, would look something like
>
> "the FooCredits system conforms with the webcredits protocol, and supports
> mailto, tel, xmpp, and openid https identities in addition to existing
> named FooCredits account identifiers"
>
> Groups of supported identity schemes might get blessed with shorter names,
> like "all webcredits level one identity schemes" but in my opinion listing
> them -- even restricting the source and destination to the URL format -- is
> wrong.
>
> I (and presumably others, such as Michiel de Jong) would like to (1) offer
> services that supports identity strings that are both urls and non-urls and
> (2) claim conformance to specifications using additive language.
>
> By "additive language" I mean, as shown above, "we are conformant, PLUS we
> support, in our conformance, this list of schemes."
>
> The alternative, when the specification enumerates a closed set of types,
> would be only delivering (1) with a weak, qualified conformance statement
> such as "we are mostly conformant, in that we use the protocol as
> specified, except that our identity strings do not include x, y, and z
> because in our experience our customers don't actually use them, and we
> also use w, v and j because they use them instead." which would be highly
> suboptimal.
>

Totally agree with you, David.

Webcredits only works if it's open ended.  Once you start restricting, you
become another me-too protocol.  Webcredits is designed to work across the
whole of http and other schemes too.

The fields source and designation were taken reused the payswarm ecommerce
vocab.  The idea is for it to be anyURI (ie anything at all).  I need to
check that the links are still working after the moves to purl.org.

I think the subtle point here that most dont get, is that http urls are
documents as defined by the protocol.  And anything inside the documents as
denoted with a # are data points.  The hard thing in this is web developers
having to UNLEARN their previous assumptions.  This single point causes no
end of chaos!  The other problem is that the web, like html, is fault
tolernt, so that if you get it wrong your system will probably still work!
:)

The challenge is to getting the language right so that it's easily
understood in the short spec doc., in particular so that people can get up
and running in under a day.  I'm going to put out a draft in the next few
days that is hopefully more understandable.