[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Regrep request by unique ID
Attached is the previous section on THTTP, with a short intro para. Looking at it, I don't quite understand what people are not understanding about it, so I left it pretty much as is. regards, Terry
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>OASIS Registry and Repository - Request by Unique Identifier
</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.11">
</head>
<body>
<h1 >
<a name="N236">OASIS Registry and Repository - Request by Unique Identifier
</a>
</h1>
<hr>
<p>
<b>Table of Contents</b>
</p>
<dl>
<dt>1. <a href="#request">Request by Unique Identifier</a>
</dt>
</dl>
<h2 >
<a name="request"><b>1. Request by Unique Identifier</b></a>
</h2>
<p>An interoperable network of registries requires at least
one agreed-upon protocol for obtaining resources and their metadata.
Fortunately, such a protocol was specified in the course
of URN development work in the IETF.
</p>
<p>Resolution of requests by URL and URN are discussed in
<a href="http://www.ietf.org/rfc/rfc2483.txt" >RFC 2483,
URI Resolution Services Necessary for URN Resolution</a>.
This an experimental specification appears to be well suited
to the purposes of the OASIS Registry and Repository Technical Committee.
Its typology of requests, results,
errors, and security considerations is well considered.
</p>
<p>As the OASIS Registry and Repository Technical Committee is willing to limit the protocols supported
to HTTP, the
syntax proposed in RFC 2169, “A Trivial Convention for using
HTTP in URN Resolution” (THTTP) is specified here, with
revisions to bring it in line with
the later RFC 2483, to wit, replacement of the L2* and N2*
requests with a generic I2* request.
Thus emended, section 2.0 of RFC 2169 reads:
</p>
<blockquote>
<p>
The general approach used to encode resolution service requests in
THTTP is quite simple:
</p>
<pre >
GET /uri-res/<service>?<uri> HTTP/1.0
</pre>
<p>
For example, if we have the URN "urn:foo:12345-54321" and want a URL,
we would send the request:
</p>
<pre >
GET /uri-res/I2L?urn:foo:12345-54321 HTTP/1.0
</pre>
<p>
The request could also be encoded as an HTTP 1.1 request. This would
look like:
</p>
<pre >
GET /uri-res/I2L?urn:foo:12345-54321 HTTP/1.1
Host: <whatever host we are sending the request to>
</pre>
<p>
Responses from the HTTP server follow standard HTTP practice. Status
codes, such as 200 (OK) or 404 (Not Found) shall be returned. The
normal rules for determining cachability, negotiating formats, etc.
apply.
</p>
</blockquote>
<p>To use this syntax in general, one would follow the pattern
(cast as a URL rather than a full HTTP request):
</p>
<pre >
http://someregistry.org/<function>?argument
</pre>
<p>To obtain an entity such as the Docbook DTD (the URN is
imaginary):
</p>
<pre >
http://someregistry.org/I2R?urn:x-oasis:dtds:Docbook-v3.1
</pre>
<p>To obtain the composite metadata document
for the Docbook DTD (the URN is
again imaginary):
</p>
<pre >
http://someregistry.org/I2C?urn:x-oasis:dtds:Docbook-v3.1
</pre>
<p>
RFC 2483 defines an “I2C” request (section 4.5), for resolution
of a URL or URN to a description of a resource (URC). As this is
a generic request, the OASIS Registry and Repository Technical Committee chooses not to require registries
conformant with this specification to return
an entity's registration document in response to this request;
registries are free to supply whatever their preferred metadata
is, which may extend that specified here. (An RA may set its
own policy with respect to what metadata it will accept beyond
that specified here.) Instead,
an additional request, I2X, is specified as returning the
entity's registration document as defined here. Some
information, such as personal contact information, may be withheld
by the RA, perhaps on the basis of the identity of the
requestor, if such is its policy.
</p>
<p>
The “I2CS” request, section 4.6, allows a request
for multiple documents; in the absence of agreement on XML
packaging, it is not clear that it would be useful to implement
it at the present time.
</p>
</body>
</html>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC