Subject: [alto] ALTO Interop document updated (v0.9)

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 18 Jul 2011 13:14:49 -0500

Folks: Manish <[email-masked]> contributed test cases
7, 8, 9, and 18 (thanks, Manish).

With this contribution, the ALTO test document is almost
complete, except for one more test case --- Test Case 19.

The current test case document (version 0.9) is attached.
Please take a look at the newly added test cases (7, 8, 9, and
18) and make sure these look reasonable.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Mikio Hara <[email-masked]>
Date: Tue, 19 Jul 2011 18:27:36 +0900

> The current test case document (version 0.9) is attached.

Just a nit.

> 6) Retrieving a cost map (Section 5)
> GET /costmap/num/routingcost HTTP/1.1

s/num/numerical/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Jul 2011 09:51:58 -0500

On 07/19/2011 04:27 AM, Mikio Hara wrote:
> On Tue, Jul 19, 2011 at 3:14 AM, Vijay K. Gurbani<[email-masked]>  wrote:
>

OK, good catch.  That way, the abs_path agrees with
URI returned in Test Case 1.

I will modify the test case document and release a final
one before the interoperability.

Thanks,

- vijay

---

From: "Zhang, Ning" <[email-masked]>
Date: Tue, 19 Jul 2011 11:29:40 -0400

Vijay,

Here are some comments about the test cases.

Thanks,
-Ning

Test case 1:

Should the following URIs

"uri": "http://alto.ietf.org/costmap/numerical/routingcost"
"uri": "http://alto.ietf.org/costmap/ordinal/routingcost"
"uri": "http://alto.ietf.org/endpoints/cost"
"uri": "http://alto.ietf.org/endpoints/property"

be changed to:

"uri": "http://alto.ietf.org/costmap/num/routingcost"
"uri": "http://alto.ietf.org/costmap/ord/routingcost"
"uri": "http://alto.ietf.org/endpointcost/lookup"
"uri": "http://alto.ietf.org/endpointprop/lookup"

Test case 12:

POST /endpointprops/lookup HTTP/1.1

needs to be changed to:

POST /endpointprop/lookup HTTP/1.1

Test case 16:

The extra "," needs to be removed in the response:

   {
      "meta" : {},
      "data" : {
         "map-vtag" : "1266506155",
         "map" : {
            "mypid2" : {
               "ipv4" : [ "192.168.0.0/16" ]
            },
         }
      }
   }

Test case 17:

One "," is messing after the first "]" in the request:
   {
     "cost-mode" : "numerical",
     "cost-type" : "routingcost",
     "pids" : {
       "srcs" : [ "mypid1", "mypid3" ]
       "dsts" : [ "mypid2", "peeringpid1", "transitpid2" ]
     }
   }

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
Sent: Monday, July 18, 2011 2:15 PM
To: alto
Subject: [alto] ALTO Interop document updated (v0.9)

Thanks,

- vijay

---

From: Richard Alimi <[email-masked]>
Date: Tue, 19 Jul 2011 08:34:05 -0700

Perhaps I am missing something, but in Test Case 1, should it read
"Server returns the following directory or one with equivalent
Information Resources"?  Or, is there a reason for server
implementations to use a particular resource entry layout and URIs?

Rich

On Mon, Jul 18, 2011 at 11:14 AM, Vijay K. Gurbani <[email-masked]> wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Jul 2011 10:57:12 -0500

> implementations to use a particular resource entry layout and URIs?

Rich: It is not expected that all servers return the response in
the format shown in the test document.  Server implementations will
vary in how they marshal up the payload, as long as it is
syntactically valid and semantically equivalent to any other
response.

I have added your suggestion to Test Case 1, in any case.

Thanks,

- vijay

---

From: Richard Alimi <[email-masked]>
Date: Tue, 19 Jul 2011 08:59:36 -0700

> I have added your suggestion to Test Case 1, in any case.

Okay - I expected JSON format (member ordering, whitespace, etc) to be
up to the implementation, but just wanted to be clarify that the
server didn't have to choose its resource -> URI mapping as well.
Semantically equivalent at the Information Resource level (not at the
JSON level) sounds good to me :)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Jul 2011 11:55:06 -0500

> Here are some comments about the test cases.

Ning: Thanks for your review.  More inline.

> "uri": "http://alto.ietf.org/endpointprop/lookup"

I have modified it so that the URIs in the specific
test cases now agree with the URIs in the information
directory returned in Test Case 1.

> The extra "," needs to be removed in the response:

Done.

> One "," is messing after the first "]" in the request:

Done.

I will release a new version of the document shortly.  Please
make sure that your comments have been addressed.

Thanks a lot.

- vijay