[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: LAST CALL: draft-ietf-asid-ldapv3-simplepaged-02.txt
Ya know, I just reread this thread and realized that Frank and I are in
violent agreement, at least about allowing robust services.
I guess I just jumped all over the "thin client" reference: I don't
think you need thin clients to argue in favour of services such as paged
results: you can base the argument on a desire to "spread the pain"
around, such as having the server maintain result state in order so that
the client needn't maintain data - say, if it is simply sanity checking
or performing minor updates to large numbers of entries - and in order
to keep network load level... ...it all depends on your operational
requirements... ...and thin clients are a wave of the future, not the
wave....
:->
pww, who will remember to think at least *3* times prior to responding
from now on....
>----------
>From: Peter Whittaker
>Sent: Thursday, February 26, 1998 2:04 PM
>To: Ed Oskiewicz; 'Frank Dawson'
>Cc: ietf-ldapext@netscape.com; ietf-asid@netscape.com
>Subject: RE: LAST CALL: draft-ietf-asid-ldapv3-simplepaged-02.txt
>
>From: Frank Dawson[SMTP:fdawson@earthlink.net]
>The industry believes that "thin clients" are the way to go. Pushing back on
>providing robust "services" in the server is myopic.
>
>I'm very suspicious of claims that the industry is heading in any particular
>direction. For some purposes, thin clients may well be the way to go. For
>others, they most definitely are not. Excluding or rejecting particular
>enhancements or extensions on the grounds that many if not most
>implementations are unable or unwilling to take advantage of them seems
>counter to the spirit of innovation that characterizes the best work of the
>IETF and its participants (and I daresay that say of other standards bodies).
>
>After all, the capabilities under discussion are extensions to an existing
>(and theoretically "thin") protocol, a protocol designed with such extensions
>in mind. They are in no way mandatory, and in fact are likely to be of
>interest to only a relatively small subset of the Internet community.
>Fortunately, the IETF's process is designed to handle this, with RFCs
>characterized as required (thou shalt do this), recommended (if do anything
>along these lines, thou shalt do it this way) and informational (here's a way
>to do something, you're under no obligation to pay any attention, caveat
>emptor, YMMV).
>
>pww
>
>
>
>
>