# Re: New URC Specification is ready....

Michael Mealling (ccoprmm@oit.gatech.edu)
Fri, 8 Jul 1994 16:03:36 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Michael Mealling: "Re: New URC Specification is ready...."
- Previous message: Daniel W. Connolly: "Re: URC Author Section"
- In reply to: Jim Davis: "Re: New URC Specification is ready...."

    From: ccoprmm@oit.gatech.edu (Michael Mealling)

    Message-Id: <199407082003.AA14644@oit.gatech.edu>

    Subject: Re: New URC Specification is ready....

    To: davis@DRI.cornell.edu (Jim Davis)

    Date: Fri, 8 Jul 1994 16:03:36 -0400 (EDT)

    In-Reply-To: <199407081333.AA26477@willow.tc.cornell.edu> from "Jim Davis" at Jul 8, 94 09:33:27 am

Jim Davis said this:
> 1) Perhaps the URC itself requires some meta-data, e.g. the date/time
> it was created and the server from which it came. See comment about
> TTL below. I am assuming that one might want to keep a URC for
> minutes, days, even forever, like a card in a card catalog. In that
> case the meta-info becomes more important.

True.

> 2) I think the precedence rules are a mistake because they are not
> flexible. For example, right now, a TTL is associated with the
> previous tuple only. But suppose you wanted to add another entry that
> was just like the TTL, in that it refered to one and only one entry.
> You could not do it, since which ever one came second would not get
> the right target. e.g. you want to say
> URL: foo
> Cost: $25
> TTL: 1 day
> Bandwidth: low
>
> In your system the TTL would apply to Cost not to the URL. (Hopefully
> the indenting makes my intent clear. Indeed I would claim that you
> should use indenting, except that you use leading whitespace as a
> continuation character.

What about a rule like this:

URL:foo
TTL: 36000
Cost: $25
Bandwidth: low

This means that:

a) the URL has the TTL of 3600.
b) the URL has precedence until the next occurence of URL:
c) therefore, since everything until the next URL DEPENDS on that URL,
when it expires then everything in that tuple expires.

Does that make sense?

> 3) How could you record negative information, e.g. suppose you want
> to write down the fact that a certain URL *used* to work, but no
> longer does?

Hmm...Maybe a negative TTL? ;-)

TTL: -3600

i.e.: this worked yesterday but not today.

hehe....this one could get funny...

> 4) You need to specify what character set you wish to use and how
> extensions to the char set will be encoded, e.g. names in non-ASCII.

Good point. I missed that one. I'll add it next iteration.

> 5) what if the attribute contains a colon? Is there a way to encode
> it?

No attribute can contain a colon. If there is sufficient uproar raised then
we can come up with some escaping mechanism but I hate to clutter the
specification with it.

> 6) is whitespace after the colon significant or not?

Yes. This ommision was pointed out after I sent it out. If there is
white space after the : then leading white space in the value is
non-significant. If there isn't one then leading white space IS significant.

> 7) Author. How will multiple authors be encoded? How about Corporate
> Authors? It would be useful to get a clear standard on this so that
> URCs can function as bibliographic records.

I'm not aware of any work that has been done in other areas. That doesn't
mean that there isn't any. ;-) Corporate Authors: sounds reasonable as well.
Multiple Authors could be delimited with a semicolon

> 8) What is the time origin of TTL? Seconds since when?

Seconds since whoever said so. Icky ain't it. I expect TTL to evolve a
great deal before it gets really useful. Maybe a full TTL field with
different encoding methods and such.

> 9) Is anyone thinking about how to express terms and conditions of
> intellectual property usage? I don't think these should necessarily
> go into the URC (a pointer to the info would be better.) nor should
> the URC spec be delayed while these are designed. But they are
> very important issues and *someone* should think about them.

Definilty. This is the how things should progress. We develop other useful
things without slowing down the overall architecture. I don't know all of
the issues relavent in this area but I'm sure someone on this list should.
;-)

> 10) Finally, two trivial issues:
> 1) the HTML document would be easier to read if you used DL instead
> of IL. It would also make it easier to automatically find the
> attributes, since they'd be tagged with DT.

So noted. To be changed next week in the HTML version.
(I love living documents!)

> 2) In the example of Abstract, you spelled "laden" wrong.

hmm...ispell missed that one......

> best wishes

Thanks for the comments!

-MM

    --
    ------------------------------------------------------------------------------
    <HR><A HREF="http://www.gatech.edu/michael.html">
    <ADDRESS>Michael Mealling</ADDRESS>
    <ADDRESS>michael.mealling@oit.gatech.edu</ADDRESS></A>

- Next message: Michael Mealling: "Re: New URC Specification is ready...."
- Previous message: Daniel W. Connolly: "Re: URC Author Section"
- In reply to: Jim Davis: "Re: New URC Specification is ready...."