From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199407130248.AA16851@oit.gatech.edu>
Subject: Re: New URC Specification is ready....
To: masinter@parc.xerox.com (Larry Masinter)
Date: Tue, 12 Jul 1994 22:48:55 -0400 (EDT)
In-Reply-To: <94Jul12.182312pdt.2760@golden.parc.xerox.com> from "Larry Masinter" at Jul 12, 94 06:23:06 pm
Larry Masinter said this:
> > You got any suggestions?
>
> I think there are two choices (someone correct me if there are more):
>
> 1) the URC is a document, and, as such, is encoded in a character set.
>
> Content-type: text/urc; charset=US_ASCII
>
> Author: Masinter, Larry
This probably won't fly since different fields could and probably will be
in different character sets.
> 2) each attribute value is (possibly) a document, and needs a way to
> encode it within the URC.
>
> I don't actually understand how to accomplish 2 if URCs are also
> expected to be `transport friendly', i.e., themselves included in
> text/plain; charset=US_ASCII messages.
If I remember correctly the definition of transport friendly was that
could be transferred within common internet protocols. I don't think
URCs can be transport easy, just transport friendly. Does that make sense?
whois++ handles this by means of a multipart MIME response FORMAT which
would essentially break the URC up into specific MIME sections per
characterset DURING transport from the whois++ server. While this
makes them much harder to parse it is another solution, albiet an
implementation specific one.
Why don't we table this one and see if anything dealing with character sets
comes out of Toronto? I understand character sets are a hot potato these
days so it might be best to see what falls out during Toronto.
-- ------------------------------------------------------------------------------ <HR><A HREF="http://www.gatech.edu/michael.html"> <ADDRESS>Michael Mealling</ADDRESS> <ADDRESS>michael.mealling@oit.gatech.edu</ADDRESS></A>