[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
One view of the transport problem
Note that I am personally very interested in all groups that
"start from the beginning", so I have been thinking a while if I should
post this message. I don't want to say something like "I want you
to use Whois++" - I just want to give a different view of the problem.
At Bunyip we are working with the index-based directory service called
Whois++. I don't know how familiar you are with it, but it is basically
a TCP-based protocol which uses a template format (i.e. record type
and then attribute name/attribute value pairs) for the output.
You can connect to services.bunyip.com:7778 and see what I mean.
Give the command (search-token actually) "paf" and press return
and you see what happens.
The protocol is specified in RFC-1835, and is defining a textual
protocol where you can still send arbitrary length attribute values
(i.e. linebreaks can be part of the value OR inserted because of
the transport). Spaces etc are equally safe.
Whois++ already uses UNICODE (i.e. the UTF-8 encoding) and the part
of the server we have (Digger) which handles UNICODE will be freely
available as fast as we can. It handles decomposition etc for you.
I.e. you will get a libunicode.a as soon as we have the API ready.
As it is now, it is a little bit too tightly coupled with the Digger
So, UNICODE _is_ a serious proposal as I see it.
Whois++ also allows global searches, so what you can get back is
a referral to other servers, and not the data itself. You can
also have multiple hierarchies of records, and not only one
parent of each server as you can in X.500.
Anyway, let me know if you think it is suitable for a presentation
of Whois++, or rather what we have solved in Whois++, to give a
view of what problems you should try to solve in this group.
I think Whois++ can be suitable as a transport mechanism for
certificates as soon as we have a definition of the certificate
itself as a list of attributename/attributevalue pairs.