On Tue, Nov 6, 2012 at 7:15 AM, Vijay K. Gurbani <[email protected]> wrote:
> On 11/05/2012 10:29 PM, Y. Richard Yang wrote:
>
>> Hi Vijay,
>>
>> I think we know the issue of the extra numbers before and after the
>> json return: the server used chunked encoding:
>>
> [...]
>
> A client supporting chunked encoding will remove those number and a
>> client (e.g., nc) does not will keep them.
>>
>
> Richard: OK, that explains the numbers in nc output.
>
>
> The examples in the current spec all use content length. Do we want
>> to say something here or not?
>>
>
> I am leaning to no primarily because rfc2616 makes it mandatory to
> receive and decode the chunked transfer encoding. Since nc is not
> rfc2616 compliant, but we require ALTO clients to be (section 6.3 of
> the ALTO protocol), I think we do not need to specify anything more.
>
>
FWIW, I believe in an earlier version of the draft we were more explicit
and specified that clients must support chunked encoding. The guidance we
received at that point was to not reiterate details from the rfc2616.
Rich
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} /
> vijay.gurbani@alcatel-lucent.**com<[email protected]>
> Web: http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/>
>
>
> ______________________________**_________________
> alto mailing list
> [email protected]
> https://www.ietf.org/mailman/**listinfo/alto<https://www.ietf.org/mailman/listinfo/alto>
>
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
