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

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.