Re: [alto] Current status and a way forward for ALTO

[Richard Alimi <[e-mail]>]

Thank you very much Enrico for helping to target the discussions.

My opinions on the outstanding issues that you mentioned below:

On Fri, Mar 1, 2013 at 7:12 AM, Enrico Marocco <
[e-mail]> wrote:

> Hi all,
>
...

> - get acquainted with the issues that have been discussed since the
>   previous meeting, including (in no particular order):
>     o reason phrase for error messages;
>

I'd prefer to leave it out, but I don't feel strongly. Ted Hardie proposed
to remove it in his review of the draft, citing that free-form strings
typically introduce more complexity due to internationalization.  If it is
added back, I would propose that it be a US-ASCII string, just like the
other strings already in the protocol.

    o relative vs. absolute URIs;
>

I believe that allowing relative URIs is a good thing.  Speaking from some
experience, it actually would have simplified my implementation.


>     o behavior of degenerated map filtering;
>

I support returning the whole map when the list of sources and destinations
are empty.


>     o merge of cost-mode and cost-type in a single type;
>

I'd prefer to keep them separate. I believe that the proposals for merging
them will make the registry very messy and cumbersome when new cost types
are registered.

There has been discussion over whether cost mode is useful.  I believe it
is for the following reasons:
(1) There are good use cases for numerical costs (e.g., P4P).
(2) There are good use cases for ordinal costs (e.g., the proxidor
approach).
(3) Removing support for either numerical or ordinal costs means that we
are going to revisit one of the discussions from very early on in the
working group, where people worked together quite well to merge 3 drafts
into a single alto protocol.
(4) It should be up to the server as to whether it supports numerical or
ordinal costs, and a client needs to be able to tell which it is receiving

Cost Mode is currently the way we communicate how the client should treat
the costs it has received from the server.


>     o format of endpoint properties;
>

The current draft allows them to be generic json values (not only strings),
though the base protocol only requires clients to understand strings.

This is exactly how we treat cost values today, and I don't see a reason
for it to be different.

Extensions can define property and cost values that have other formats,
such as arrays, objects, etc.


>     o mandatory vs. optional services;
>

I don't think there has been much debate over what is mandatory and what is
optional, right?   Can you point me to this discussion?


>
> - review the latest version of the protocol, with special attention on
>   the above-mentioned issues;
>
> - share your opinion on the list. Please note that this is essential
>   for us to determine consensus, so, regarding the open issue
>   resolution options, even a motivated "don't care" is useful feedback.
>
> We'd like to ask the editors of the protocol draft to circulate an
> update on the changes of the latest version, creating a good starting
> point for discussion.
>
> If we will be able to determine consensus for moving the document
> forward before the face-to-face meeting (that this time comes very late
> in the week, and longer than requested), we will be happy to bash the
> agenda on the list and possibly allocate extra time for unchartered
> topics that at this time don't have a slot.
>
> Comments are welcome.
>
> Enrico
>
>
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>
>