Subject: Re: [alto] alto Digest, Vol 32, Issue 19

From: Bill Roome <[email-masked]>
Date: Tue, 21 Jun 2011 13:17:59 -0400

>If you still feel strongly, it seems like we are at an impasse among
>the two of us. That's fine and it can be resolved by the WG and we'll
>update the document according to what the WG decides.  There are
>considerations on both sides of the issue which have been recounted.
>At this time it would be good to get feedback from others in the WG to
>help resolve the debate.
>
>To summarize, there are 3 possible solutions I think:
>(1) Change the draft to make there be a single canonical format (that
>is, give stronger wording than RFC5952)
>(2) Require that for endpoint cost queries and endpoint property
>queries, the ALTO Server gives IP addresses in the same exact format
>as was in the request. (the wording in the draft can be adjusted, but
>please correct me if the sentiment is incorrect)
>(3) Leave the draft as-is, and let the server decide the particular
>address format.
>
>Is that a fair and objective summary of the options? If not, please
>correct me.
>
>Thoughts from others in the WG on how to move forward?
>
>Thanks,
>Rich

I agree with those choices, with one extension: For (3), the protocol spec
should explicitly say that in the EndpointCost response, the server MAY
return address string representations that are equivalent to, but not
identical to, the strings in the client's EndpointCostParam request, and
warn clients they must deal with the resulting aliasing issues.

Ditto for the EndpointProp response and EndpointPropParam request.

If the protocol doesn't say that, I'm certain that many client
implementors will assume the server always returns the same string
representation, and many server implementors will assume the opposite. The
result: lots of interoperability problems.

As for #1-#3, I think #1 is impractical. I have a mild preference for #2,
mostly because that will give better interoperability (no matter how much
we warn them, some client implementors just won't get the message). But I
don't feel that strongly about it; I can certainly live with #3, as
extended above.

Sorry if I came across too forcefully. The only thing I feel strongly
about is that the protocol spec should take a stand: either require
servers to use the same string representation, or else warn clients not to
assume that servers will do that.

	- Bill Roome

---

From: Richard Alimi <[email-masked]>
Date: Tue, 21 Jun 2011 10:29:57 -0700

Hi Bill,

> warn clients they must deal with the resulting aliasing issues.

Yes, that can certainly be mentioned explicitly in the draft if there
is confusion.

> As for #1-#3, I think #1 is impractical.

I think I would agree as I don't think we should get into the business
of textual representations of addresses. Martin seemed to indicate
that it was a possibility.

> I have a mild preference for #2,

No apologies necessary. You did not come across too forcefully; people
are entitled to opinions even if they are strong :) Disagreements
happen and it will get resolved, that's why we have rough consensus.

We can let this hang here for others to comment for a couple of days
if that is okay.

Thanks,
Rich

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

---

From: Richard Alimi <[email-masked]>
Date: Mon, 27 Jun 2011 18:14:05 -0700

Hi All,

Hoping to bring this thread to a close...

>>>Thoughts from others in the WG on how to move forward?
..
> We can let this hang here for others to comment for a couple of days

In the interest of producing the next revision of the document (to be
sent out tonight), the plan is to explicitly note in the draft that
there is no requirement for an ALTO Server to reply using the same
format for an address as was included in the request.  If there is
additional feedback from the WG contrary to this, we can continue
discussion on this thread.

Thanks,
Rich