On Tue, 26 Jul 2005, Ned Freed wrote:
>> q=xkms
>
> Ahhh. So we're talking about heavy-weight key fetching alternatives.
What are your reasons for considering HTTP to be heavy-weight protocol?
TCP? Redirects? Elaborate framing? Lots of options?
The framing is no more elaborate then SMTP really (based on it actually),
options and redirects can be restricted if desired (i.e. specified that
key server client is not required to support anything but some base HTTP
get functionality - we're not suggesting to use POST or PUT after all...).
I suspect it all comes down to TCP vs UDP, i.e. one requires establishing
a session and several packets for that (2 packets both ways I think) where
as UDP is two packets. However it appears internet applicaiton protocols
seems to all be based on TCP and in fact TCP/IP means TCP is basis for
what we now have as Internet and UDP is carried along for tasks where having
session would be harmful rathern then helpfull (i.e. media streaming where
some packet loss is acceptable).
Do you also consider SMTP or LDAP to be heavy-weight?
For fetching DKIM keys, yes, absolutely. (LDAP over UDP would be an
interesting alterntive, but I believe the UDP binding has been abandoned.)
Not abandoned, its just that LDAP users have found LDAP/TCP to be sufficient
to their neeeds at this time, inspite that there were many people who in
fact thought that it would be "heavy-weight" and not capable of handling
high load. It exactly illustrates my point as that TCP can well be used
for protocol that requires high amount of data retrieval - TCP really is
not a problem (and that is why DNS is slowly moving to TCP as well!).
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net