Re: [urn] URN R-component specification

[[e-mail] (Dale R. Worley)]

"Hakala, Juha E" <[e-mail]> writes:
> Field name for services will be s. Field name for parameters will be p.

In this conceptualization, all parameter values (values of the "p"
field) are drawn from the same value space, which generally limits them
to being "keywords".

> Initial set for service values will be derived from RFC 2483. Since
> the set of services specified in it is not enough for our project,
> some additional values will be specified; we expect that a registry of
> services and their names and service parameters will be established
> later by an appropriate body which may or may not be IETF / IANA. IESG
> or some other appropriate body should discuss this. AFAIK service
> registry does have a close relation to the registry of namespaces;
> when namespaces are registered, the registrants should also list the
> resolution services supported (if any).

Your examples essentially scope the service values to the urn:issn
namespace, which suggests that although they may be shared other PID
systems for serials, they aren't likely to be generally applicable
across all URN namespaces.  So they should be looked at as part of the
urn:issn registration, rather than as part of a global space of
"services for URNs".

> Since R-components do not have a role in identification, they do not
> need to persist, and they can be changed "on the fly" if need be.

That is, they may be changed in an incompatible way in the future.

Dale