Subject: [alto] Interoperability pairings

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 05 Nov 2012 18:42:45 -0600

Folks: By my count, we have 4 servers and 2 clients that will be
part of the ALTO interoperability.

Assume that we have servers S1, S2, S3, S4 and clients C1 and C2, I
propose that we divide our time in 1/2 hour slots to ensure that all
of the pairings are tested within 2 hours (+/- 1/2 hour or so).

Thus we have the following pairings:

8:15-8:45        8:45-9:15        9:15-9:45        9:45-10:15
S1-C1            S3-C1            S1-C2            S3-C2
S2-C2            S4-C2            S2-C1            S4-C1

If anyone has an alternative idea to proceed, please let me and
Enrico know.

At the end of the interoperability tests, can each pair please report
the following to the chairs:

Total tests attempted:
Total tests passed successfully:

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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 5 Nov 2012 23:29:44 -0500

Hi Vijay,

I think we know the issue of the extra numbers before and after the json
return: the server used chunked encoding:

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/alto-endpointprop+json
Date: Tue, 06 Nov 2012 04:33:56 GMT

82
{
"meta" : {},
"data" : {
"map-vtag" : "1352176329",
"map" : {
"ipv4:192.168.1.23" : {
"pid" : "mypid2"
}
}
}
}
0

A client supporting chunked encoding will remove those number and a client
(e.g., nc) does not will keep them. The examples in the current spec all
use content length. Do we want to say something here or not?

Richard

On Mon, Nov 5, 2012 at 7:42 PM, Vijay K. Gurbani <[email-masked]> wrote:

> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.**com<[email-masked]>
> Web:   http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/>
>
> ______________________________**_________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/alto<https://www.ietf.org/mailman/listinfo/alto>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Nov 2012 09:15:53 -0600

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.

Thanks,

- vijay

---

From: Richard Alimi <[email-masked]>
Date: Tue, 6 Nov 2012 08:53:24 -0800

> 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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 6 Nov 2012 12:46:42 -0500

Hi Rich, Vijay,

No action makes sense to me. From this experience, I may suggest that we
add a suggestive sentence about
potential issues of not handling chunked encoding, just for the benefit of
readers. What do you know?

Richard

On Tue, Nov 6, 2012 at 11:53 AM, Richard Alimi <[email-masked]> wrote:

>
> On Tue, Nov 6, 2012 at 7:15 AM, Vijay K. Gurbani <[email-masked]>wrote:
>

---

From: "Junchang(Jason) Wang" <[email-masked]>
Date: Tue, 6 Nov 2012 14:11:48 -0500

Dear all,

Or adding a single sentence about potential issues of clients which aren't
rfc2616 compliant in Section 6.3 would benefit readers a lot.

Thanks.

--Jason

On Tue, Nov 6, 2012 at 12:46 PM, Y. Richard Yang <[email-masked]> wrote:

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Nov 2012 13:15:34 -0600

On 11/06/2012 11:46 AM, Y. Richard Yang wrote:
> potential issues of not handling chunked encoding, just for the benefit
> of readers. What do you know?

Richard: I am rather conflicted on what to do.  Clearly, nc is not a
RFC2616 client, and just as clearly, any RFC2616 client will support
chunked encoding.

I also realize that we spent some time at the bakeoff looking at the
byte count prefix in nc(1) but not correlating it immediately with the
"Transfer-Encoding: chunked" header, so saying something seems
appropriate.

In the end, I think I will chalk this upto us being tired and cranky
late at night.

But, if the editor team of the protocol document can find a place to
exhort implementations to pay attention to transfer encodings applied
to message bodies without reiterating rfc2616, then please proceed.  I
tried to spend some time thinking how to do this, but could not arrive
at a reasonable set of words.  So alas, I cannot contribute any text
to get you started ...

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Nov 2012 13:20:25 -0600

On 11/06/2012 01:11 PM, Junchang(Jason) Wang wrote:
> Dear all,
>
> Or adding a single sentence about potential issues of clients which
> aren't rfc2616 compliant in Section 6.3 would benefit readers a lot.

Jason: The problem with is why stop at the specific example of Content-
Encoding?  A client that isn't compliant will rfc2616 can potentially
do anything it wants and fail in a spectacular way, or worse, cause the
ALTO server to fail in a spectacular way.

I think Section 6.3 takes a reasonable stand that ALTO clients and
servers MUST be compliant with rfc2616.  Hedging our bets and saying
that clients MAY be partially compatible opens up a larger can of
worms, unfortunately.

Thanks,

- vijay

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 6 Nov 2012 19:44:21 +0000

Vijay, Richard,

> "Transfer-Encoding: chunked" header, so saying something seems

IMO there is no need to say anything. RFCs are about interoperability. The ALTO protocol spec states that RFC2616 compliance is a MUST, therefore the specification should not make accommodation for interoperability with clients that do not conform to RFC2616.

I think doing anything else would lead to re-iterating the whole of RFC2616.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 6 Nov 2012 19:47:52 +0000

> that clients MAY be partially compatible opens up a larger can of

+1 the ALTO protocol spec is clear - to implement ALTO you need to be RFC2616 compliant. If someone wants to implement an ALTO client that isn't RFC2616 compliant then they are on their own and interoperability isn't guaranteed.

Ben

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 6 Nov 2012 15:03:55 -0500

On Tue, Nov 6, 2012 at 2:47 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> +1 the ALTO protocol spec is clear - to implement ALTO you need to be
> RFC2616 compliant. If someone wants to implement an ALTO client that isn't
> RFC2616 compliant then they are on their own and interoperability isn't
> guaranteed.
>
>
Thanks for the opinions, VIjay, Ben. We then proceed with the current
writing, without singling out some potential issues.

Vijay: if you have some write up on (experiences from) interop, chunked
coding might be listed as a potential source issue.

Thanks!

Richard

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 06 Nov 2012 15:51:06 -0600

> coding might be listed as a potential source issue.

Richard: Yes, I will do so.  One place where we can document such
"gotchas" is as part of draft-gurbani-alto-interop-cases.

The rub is that we should, then, insure that the draft gets published
instead of simply expiring.  But at least it will distill some known
issues that implementors can be wary of.

Thanks,

- vijay