Re: HTTP Methods

On Mar 9, 2004, at 10:37 AM, Patrick Stickler wrote:

..cut..
> URIQA is agnostic. Implementations are free to decide.

I'll move those to the othter summary message; and correct if
this is not presented (as I realize you answered to the message
in a URIQA specific manner - while I more meant the whole
range of options, including CreateCommons and grddl.

> However, DDDS can be employed for non-HTTP meaningful URIs to
> obtain an alias URI which is meaningful to HTTP, via which
> URIQA can provide descriptions.

Or to other protocols; like an 'ftp' alternative, a mailto or even
a specialist protocol like EOLI or that used by the LSID folk.s

> Since resolution via DDDS is anyway dependent on there being
> some other URI which is meaningful to some protocol via which
> representations can be accessed, one can't effectively have
> e.g. DDDS without HTTP.

Without -a- protocol which can be used to fetch either the resource
and/or info about the resource etc; but HTTP is just one of many;
z39.50 could be listed as the terminal protocol, as could be LSiD.

 From RFC 3403

  IN NAPTR 100  50  "a"    "z3950+N2L+N2C"     ""   
cidserver.example.com.
  IN NAPTR 100  50  "a"    "rcds+N2C"          ""   
cidserver.example.com.
  IN NAPTR 100  50  "s"    "http+N2L+N2C+N2R"  ""   www.example.com.

or even (just for illustration)

  IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@foo.se!i"     .
  IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i"  .

Giving one

	http		for Resource, Location and metadata
	z39.50	for Location and metadata (but not the resource)
	rcds		for metadata only

etc.

> they are) then fine, but ultimately, if you want data (representations
> or descriptions) then HTTP is the best game in town.

:-) :-) Well - _that_ is a point I do not quite share; there are 
actually other
protocols out there ;-) :-) which do a fine job for specialist 
communities.

Dw.

Received on Tuesday, 9 March 2004 05:14:07 UTC