Re: [Crisp] Last call comments for iris-lwz

[Andrew Newton <[e-mail]>]

I agree on all counts.

As for draft mechanics, I think this general text should be placed in  
an appendix except for the MUST/SHOULD language on the maximum size.

Does anybody have a problem with 4k being that maximum size?

-andy

On Oct 26, 2005, at 12:43 PM, Leslie Daigle wrote:

>
> I think one of the additional answers to "when to use lwz"
> is application specific.  That is, there are some applications
> of IRIS for which lwz is the right choice, or the right first
> choice, or whatever.
>
> That could be mentioned in the document.
>
> Leslie.
>
> David Blacka wrote:
>
>> Overall, I like the idea and I like the document.  However, from  
>> my  perspective, the document is missing discussion about how  
>> clients and  servers are supposed to interact using this protocol.
>> When doing some implementation work with this, I kept wondering  
>> to  myself if clients were supposed to negotiate with servers to   
>> determine mutual support of compression and maximum UDP size.  I  
>> was  also wondering how a client that supported lwz and xpc (and/ 
>> or BEEP)  would make a decision to try lwz.  I was wondering what  
>> the "message  pattern" was, basically.  And I was specifically  
>> wondering how  clients are expected to behave.
>> In an offline conversation with Andy, I got some fairly clear  
>> answers  to these questions, which I think should be in the  
>> document.  The  intent (as expressed by Andy, not by the draft) is  
>> for there to be no  explicit negotiation between client and  
>> server.  Instead, the client  attempts to use lwz, and either gets  
>> back and answer or an error.  If  it gets an error, the client  
>> moves on to the next transport (or just  fails, if none).
>> So, then the question remains about how clients decided to use  
>> lwz,  and, if the clients does use lwz, how it decided to use  
>> compression  or not.  Again, in this offline conversation, the  
>> solution was to  recommend a size to make these decisions around.   
>> That is, specify a  minimum size (in octets) that a server SHOULD  
>> accept.  This size  would also be the maximum size that a client  
>> SHOULD attempt to send  via LWZ.  So the client's decision tree  
>> might be (given the presence  of an iris-lwz service):
>>  1. Is my request less than size x, uncompressed?
>>     Yes -- send it.
>>     No  -- compress it.
>>  2. Is my request less than size x, compressed?
>>     Yes -- send it.
>>     No -- move on to next transport, or send it anyway.
>> I don't envision this sort of discussion actually precluding  
>> other  message patterns or decision trees, actually.  But I think  
>> that it is  very helpful to implementers (or potential  
>> implementers) to get an  idea of what the baseline or typical lwz  
>> interaction would be.
>> -- 
>> David Blacka    <[e-mail]>
>> Sr. Engineer    VeriSign Applied Research
>> _______________________________________________
>> Crisp mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/crisp
>>
>
> _______________________________________________
> Crisp mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/crisp
>


_______________________________________________
Crisp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/crisp