On 30-Oct-2006, at 01:00, Terry Manderson wrote:
The following is a transposition of a discussion that which fairly
accurately describes my concerns relating to Joe's comment and
Rob's reply.
I am concerned with the current draft's reliance on RSYNC as a base
line (read required) protocol for transport of the certificate
information and the CRL.
I think I had two concerns about the the way that rsync was specified:
1. Why specify (with MUSTs and SHOULDs) a particular protocol at all?
2. Given the need for a base protocol, why choose rsync?
Point 1 was answered, I think, and I agree that having a uniforum
protocol which is required to be supported has advantages for
implementors (who might otherwise be obliged to code support for many
exotic URI schemes on platforms with limited capabilities) and avoids
the situation where particular policies cannot be retrieved by some
clients because they happen to lack support for a particular protocol.
Point 2 still bothers me slightly, since it seems to me that the
rsync protocol is not documented in a sufficiently stable form for it
to be used as a base protocol for work such as this. Unless I'm
mistaken, the rsync protocol/algorithm are products of a single
talented individual and are documented in ad-hoc web pages. This
seems to present risks (e.g. of future IPR claims, or modifications
to the protocol which break interop with other rsync implementations).
It seems to me that the answer to question 1 lends itself to the
choice of a protocol which is widely implemented, for which
interoperability has been well-demonstrated, and whose specification
is stable. Given these goals, HTTP seems like a better choice than
rsync.
Perhaps this is a non-issue, but it seems to me that it ought to be
discussed.
Joe
_______________________________________________
Sidr mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sidr
