From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199407110142.AA24918@oit.gatech.edu>
Subject: Re: URC document
To: mitra@pandora.sf.ca.us (Mitra)
Date: Sun, 10 Jul 1994 21:42:43 -0400 (EDT)
In-Reply-To: <Pine.3.89.9407091359.A25518-0100000@pandora.sf.ca.us> from "Mitra" at Jul 9, 94 01:45:31 pm
Mitra said this:
> As a process, I suggest keeping this document intact, but progressing
> several smaller documents as the RFCs - Specifically I'd suggest
> excluding the description of specific tags/values from the first copy of
> the document so that we can agree on encoding first. I'd also suggest
> making hte whois++ stuff a seperate document, and throwing out section
> 4.1 (future stuff) entirely :-)
Definitly, I never intended this particular document to become an RFC.
Many of the folx in Houston wanted context so I gave it to them. The
next versions will be two maybe three different documents. I do
think they should all be released at the same time, though.
> The only comment on the encoding is to strongly support the Precedences
> idea. (Since I think I was the one to propose it, this should suprise
> noone :-) It keeps things simple for simple URC's. I'd like to see a way
> of specifying complex precedence while recognising that in most URCs it
> wont be required - something like Braces would be a simple way of doing
> this, and most URC maintainers (the non computer-science literate example
> of MM's paper) would never see them.
Hmm....I'm not sure if I like braces in a URC. I wouldn't mind them IF
they were not required. I don't want parsers to have to be any more
difficult to write than they have to be. If I could tell my parser that
if it found a '{' as the first character in a line that it could
ignore everything until the occurrence of '}' as the first character
in a line, then I would be somewhat satisfied. I would prefer to have
nothing in a URC except attribute value pairs. It makes life a hell
of a lot easier.
But I am flexible....
> Author should include the email address, as in the "From:" field of
> RFC822, e.g.
> Author: Mitra <mitra@path.net>
Definitly. As I said earlier I think all of these need work and that these
are just a reference point to start from. If they have sparked discussion
on specific parts of a URC but still allow the whole foundation to work
then they have done their job. Basically, this allows us to
compartmentalize the discussions to those who are actually interested/
knowledgable about them without affecting the whole process.
> TTL is lousy - it makes a URC dependant on the time it was created,
> Expires is a much better way of doing this, specify the specific time to
> throw it out. I also fail to understand the problem people are hving
> with understanding what it applies to, since this is covered by the
> precedence rules (I think - but maybe I'm missing something).
When I put TTL I meant Expired. Semantics, but probably important semantics.
For me, TTL was a last minute thing. It can stay or go or mutate. I dont'
care either way.
-- ------------------------------------------------------------------------------ <HR><A HREF="http://www.gatech.edu/michael.html"> <ADDRESS>Michael Mealling</ADDRESS> <ADDRESS>michael.mealling@oit.gatech.edu</ADDRESS></A>