# Re: URN to URC resolution scenario

Dirk Herr-Hoyman (hoymand@joe.uwex.edu)
Fri, 5 Nov 93 07:55:33 -0600

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Nathaniel Borenstein: "Re: A spec for showing language in MIME headers"
- Previous message: Tim Berners-Lee: "Re: First URI meeting notes"
- Maybe in reply to: Mitra: "URN to URC resolution scenario"
- Next in thread: Peter Deutsch: "Re: URN to URC resolution scenario"

    Date: Fri, 5 Nov 93 07:55:33 -0600

    Message-Id: <9311051355.AA29697@joe.uwex.edu>

    To: uri@bunyip.com

    From: hoymand@joe.uwex.edu (Dirk Herr-Hoyman)

    Subject: Re: URN to URC resolution scenario

Thanks for putting this together, Mitra. Your vision corresponds to what I
thought was supposed to be happening, and I'm glad someone has finally put
it down in paper.

The one nit I have to pick is with the whole nesting issue.

>Server->Client: URN: urn:xxx/yyy:ABCD123456
> Author: Mitra <mitra@path.net>
> URL: gopher://path.net/00/papers/mitra/urn2urc
> Format: Text/plain
> URL: ftp://path.net/pub/docs/urn2urc.ps
> Format: Application/postscript
>
>
>{Note: Whois++ needs to add a statement that order can not be arbitrarily
>rearranged in templates}
>
You are implying that your labeling scheme is the way to go, where you make
an attribute nested, as the Content-type is, under the attribute it
follows. This makes me rather nervous, I see lot's of potential for
ambiguity. What if Content-type could apply at the top level? What if we
have multiple levels of nesting?

I believe there are several other choices that have been batted around.

1) Use MIME style parameters

URL: gopher://path.net/00/papers/mitra/urn2urc ;
Format: Text/plain

2) Use the Data Elements labeling

URL-v1: gopher://path.net/00/papers/mitra/urn2urc
Format-v1: Text/plain

3) Use begin/end markers

{
URL: gopher://path.net/00/papers/mitra/urn2urc
Format: Text/plain
}

or even SGML

<url content-type=Text/plain>gopher://path.net/00/papers/mitra/urn2urc</url>

I imagine that 1 and 2 are real choices. The Data Elements labeling would
be the least abiguous and would scale up thru multiple levels. Your
proposal is a real choice too, as it would be easy to implement simple
cases. I'm just afraid it would not scale well.

Something from 3, and I like SGML alot here, would be a later addition, as
it would impede adoption if we started here. But, SGML has the features to
solve both nesting and language issues. I don't want to muddy up the murky
waters by pushing for this right now, but I could see passing around
templates in SGML.

Regards,

- Next message: Nathaniel Borenstein: "Re: A spec for showing language in MIME headers"
- Previous message: Tim Berners-Lee: "Re: First URI meeting notes"
- Maybe in reply to: Mitra: "URN to URC resolution scenario"
- Next in thread: Peter Deutsch: "Re: URN to URC resolution scenario"