Re: [hybi] hum(s) followup

[Salvatore Loreto <[e-mail]>]

On 8/13/10 1:35 AM, Maciej Stachowiak wrote:
> On Aug 12, 2010, at 12:14 PM, Salvatore Loreto wrote:
>
>    
>> Today ends the call for consensus/verification on the three hum(s) asked during
>> the F2F meeting in Maastricht as per mail:
>> http://www.ietf.org/mail-archive/web/hybi/current/msg02954.html
>>
>> the list has been really active during the last week, with a lot of discussions and proposals.
>> Thank to all of you for the time and the energy you are putting to move the protocol forward.
>>
>>
>> 1) for the hum#1 asked in the mail:
>> http://www.ietf.org/mail-archive/web/hybi/current/msg02960.html
>>
>> nobody raised technical reason against.
>>
>> so the chairs declare consensus on it!
>>
>>
>>
>> 2) for the hum#2 asked in the mail:
>> http://www.ietf.org/mail-archive/web/hybi/current/msg02961.html
>>
>> nobody raised technical reason against.
>>
>> so the chairs declare consensus on it!
>>
>>
>>
>> 3) the hum#3 asked in the mail:
>> http://www.ietf.org/mail-archive/web/hybi/current/msg02964.html
>>
>> has received a lot of traffic in the ml (around 60 mails from more then 15 distinct contributors)
>> the discussion has reached a state where there is a rough consensus for including within
>> the framing :
>>
>> - the ability to fragment a message because it helps in several scenarios
>>   (e.g. avoid extra buffering when the length of a message is not known upfront; allows signaling
>>    an error when something bad happes; etc.)
>>
>> there is also a rough consensus for:
>>
>> - having a large length field within the framing, so to be able to send very large files in a single frame
>>   (taking advantages of sendfile or equivalent methods)
>>
>>
>>
>> The chairs ask Gabriel and Maciej (the requirements draft authors) to update their draft to reflect the consensus
>> and submit a new version soon.
>>      
> Can you indicate which of these decisions should affect the requirements document, as opposed to the actual protocol draft, and if so what changes are appropriate? It seems to me that most of these are technical details which are relevant to the spec, but not the requirements document, at least directly.
>
> For example, the following makes sense to me as a requirement:
> (A) The protocol must support sending of large unknown-size messages without buffering.
>
> But the following does not make sense to me as a requirement:
> (B) The protocol must support the ability to fragment a message.
>
> As I see it, (A) is a requirement based on use cases, (B) is an implementation strategy to meet requirement (A), among others. It is certainly within the WG's mandate to choose implementation strategies, but it does not make sense to me to record those choices in the requirements document.
>
> Could the chairs please clarify what specifically should be changed in the requirements document?
>
> Regards,
> Maciej
>    

hi Maciej,

here we are not talking of technical details, we are talking about 
general requirements that have been checked for consensus and have 
received it.
Now we have just include them in the requirement draft and yes this wg 
has decided that

"The protocol must support the ability to fragment a message"

is an acceptable and clear requirement.

How they will be implemented is still under discussion, indeed the 
actual framing has not been decided.

br
/Sal