Subject: [alto] ALTO protocol: REST-ful vs. REST-like

From: Enrico Marocco <[email-masked]>
Date: Mon, 14 Mar 2011 16:43:23 +0100

Hi all,

as the face-to-face meeting is approaching, the chairs would like the
working group to focus on what at this time is probably the biggest
outstanding issue with the protocol document, i.e. whether it should
follow a strict REST-ful approach or a simpler REST-like one. The goal
is to have some discussion between now and the meeting and hopefully
converge toward consensus in Prague.

We understand that both approaches have pros and cons in terms of
flexibility and complexity. We would thus like to solicit people to
express their opinions on the topic, in order to better understand costs
and benefits of either case.

-- 
Ciao,
Enrico

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 15 Mar 2011 14:11:01 +0000

Hi Enrico,

For people not that familiar with web technologies (like me ;) : 
What is a good source to understand what is REST-ful and REST-like?

Thanks in advance

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Enrico Marocco
> Sent: Monday, March 14, 2011 4:43 PM
> To: [email-masked]
> Subject: [alto] ALTO protocol: REST-ful vs. REST-like
> 
> Hi all,
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 15 Mar 2011 09:19:24 -0500

> What is a good source to understand what is REST-ful and REST-like?

To paraphrase an oft-used cliché: "Go to the source, Martin!"

Roy Fielding's thesis (available at [1]) first propositioned
(I believe) the REST architectural style.  Specifically chapters 5
and 6 of the thesis should give you a good indication of the
architectural style.

[1] 
http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Ciao,

- 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: Enrico Marocco <[email-masked]>
Date: Tue, 15 Mar 2011 16:38:07 +0100

> To paraphrase an oft-used cliché: "Go to the source, Martin!"

With a very rough approximation -- that will certainly make some people
cry and scream loud -- in contrast to RPC architectures, a REST-ful
service is modeled in terms of persistent resources (think of files)
hosted on servers and accessed by clients. In other words, "everything
is a resource." The Wikipedia entry provides a nice introduction to the
REST-ful approach, as well as a good description of its main advantages:
http://en.wikipedia.org/wiki/Representational_State_Transfer

While a REST-ful approach may be the natural way to go for the
network+cost map interface, at this point it is not clear (at least to
me) how it would apply for other interfaces such as the ranking service.
As I understand it, it would complicate things (imposing the use of
awfully long URIs for instance) providing in fact little or none of the
usually associated benefits (e.g. cacheability).

On the other hand, REST-like was used to define the compromise approach
adopted in draft-ietf-alto-protocol-06 (haven't had the chance to go
through -07 yet). It would be very useful to hear opinions from people
that have been involved in the discussion so far, to get to a common
understanding of the pros and the cons of either approach.

-- 
Ciao,
Enrico

---

From: Jan Medved <[email-masked]>
Date: Tue, 15 Mar 2011 08:50:09 -0700

Hi,

as for restfulness, it certainly would be better if we could do service
discovery, as that provides a more flexible way of extending the
protocol. But care has to be taken to specify (and have the RFC require)
relative services URLs, not absolute. Reason for that is that the ALTO
server may be sitting behind a mod_proxy-style proxy, which can do
URL/header rewriting, but obviously cannot rewrite document bodies
(which is where the service endpoints are defined).

Since we are on the topic of draft, it would be really helpful if PID
names could contain some kind of special characters, to enable visual
structure for people. Also it would be really nice to have at leat 65
different characters available -- that would allow us to use BASE64 to
encode small amounts of arbitrary data in PIDs ;-)

Thanks,
Jan

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 15 Mar 2011 17:14:26 +0000

Enrico, Colleagues,

Although I've been subscribed to the mailing list for some time I've only just started to find time to look at ALTO in any detail.

> converge toward consensus in Prague.

I would argue strongly for taking a RESTful approach. From my reading of draft-ietf-alto-protocol-07 I don't see anything in there that could not be done in a RESTful manner.

I will be in Prague and I'm willing to offer to help prior, during & after Prague to redesign and update the document/protocol to make it "RESTful" if that is the direction the WG wishes to take.

BTW When I say "redesign" I don't think there is much redesign required of your data types, it is more a case of restructuring the way you define (and discover) URIs and extending some of your data types to carry information that currently you require to be hardcoded into ALTO clients.

Regardless of the definition of RESTful which can sometimes end up in a philosophical debate around semantics, below I have listed some downsides to the approach currently taken that occurred to me from a first reading of the draft:

The current draft re-specifies or prescribes behaviour for particular sub-features of HTTP. Without extensive analysis and comparison (which I have not done) it is not easy to tell whether the "profile" specified in the draft is compatible with HTTP/1.1 or contradicts RFC2616 in some way. This places an unnecessary burden on implementers to do such analysis and presents the risk that implementers may not be able to use standard HTTP library code to implement ALTO clients and servers and therefore may negate the obvious benefits of being able to reuse standard library code to implement the underlying HTTP transport. Furthermore it risks causing additional interoperability issues as it opens up the potential for ambiguity of interpretation on how to implement the ALTO "profile" of HTTP rather than letting implementers (and the ALTO WG) concentrate on the data types and services you wish to carry over HTTP. Compatibility with existing HTTP infrastructure including proxies, caches and CDNs is also increased.

The use of fixed Request-URIs may appear to be a simplification but it enforces a certain rigidity on implementations that may be undesirable and is unnecessary. For example, combined with the desire to keep "the ALTO Server implementation free from parsing and directing each request based on version number" it forces a requirement to use a separate hostname per deployed protocol version which is an unnecessary restriction. You already have a Server Information Service for discovering ALTO servers and the protocol versions they support and so it would be a simple extension to the Server Information Service (if you didn't use fixed Request-URIs) to enable multiple protocol version to co-exist on the same hostname.

The draft makes use of "templated" URIs for some functions. IMO coding to support templated URIs is not significantly less onerous or complex than coding to support the link discovery that would be necessary to convert your templated Request-URIs into RESTful URIs.

The draft combines the use of POSTs with Request bodies and querystrings. While not in contravention of RFC2616 it is pretty horrible and ugly IMO. You could achieve the same result by encoding the querystring in the Request body or by performing a GET (or if the Request is not idempotent a POST, although personally I don't like POSTs with querystrings) with a query string.

Ben

-- 
Ben Niven-Jenkins 
Senior Architect, Velocix

---

From: Richard Alimi <[email-masked]>
Date: Tue, 22 Mar 2011 00:11:31 -0700

Hi Jan,

> (which is where the service endpoints are defined).

I think that is an interesting use case.  In the general case, I would
agree. Do you envision a proxy sitting in front of an arbitrary ALTO
server, or one that is also controlled/configured within the same
administrative domain?  If it's in front of an arbitrary ALTO server,
then I think I would agree with that limitation. (In the other case,
it seems like it would be possible to configure the ALTO Server
appropriately so that all advertised endpoints were handled by the
proxy anyways.)

> structure for people.

I think that's a reasonable request. So noted :) I have no strong
preferences here, other than to mention that '_' is permitted in
variable names in many programming languages, so it seems reasonable
here as well. Suggestions?

(Note that the intent to reserve '.' is to allow something like
hierarchical PIDs or scoping in the future, so it might be confusing
to allow other characters that are used for scoping in other languages
such as ':', especially if the intent is visual separation and keeping
this clean going forwards.)

> Also it would be really nice to have at leat 65

Sneaky :)  I don't have a preference here either; sounds reasonable to me.

Rich

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

---

From: Richard Alimi <[email-masked]>
Date: Tue, 22 Mar 2011 00:38:09 -0700

Hi Ben,

Thank you very much for the feedback. Please see inline.

> I will be in Prague and I'm willing to offer to help prior, during & after Prague to redesign and update the document/protocol to make it "RESTful" if that is the direction the WG wishes to take.

That would be greatly appreciated (if, of course, the WG decides to go
that way). Thank you for the offer.

> BTW When I say "redesign" I don't think there is much redesign required of your data types, it is more a case of restructuring the way you define (and discover) URIs and extending some of your data…

Agreed. We had consciously tried to keep the messages self-contained,
and I think the major items that are up for debate are exactly the two
items you pointed out below.

Note that this is more-or-less where a 'compromise' approach came in.
To expand a bit further on what we wrote in the discussion section
10.6 of the -07 draft, one possibility was to separate the draft in
terms of structure, but not change the semantics, such that the data
structures and message encodings were separate from the rest. If done
right, that could make it easier to design a REST-ful extension to the
protocol.

That said, I do personally feel somewhat hesitant to take a
middle-of-the-road approach. If we can settle on the "right" way to go
now, then it seems reasonable to just put in the 2-week effort to make
a significant update to the draft.  That would present less
opportunity for divergent implementations down the line.

>  s and CDNs is also increased.

While this might be a reasonable concern, I'm wondering if this is
actually a problem.  I believe the contents of the draft are all
fairly standard uses of HTTP, and it was drawn from implementation
experience as well. Given that there are more than a few groups with
implementations, if people needed to hack HTTP library implementations
to get it to work, I'm sure we would have heard about it. :) That
said, if there actually are issues that cause anyone to touch a line
of an existing, reasonable HTTP client or server library to implement
this, please let us know, and it should be fixed.

Apologies for drawing that distinction, but I think it would be good
to keep this thread to the technical merits of REST-like vs. REST-ful
as opposed to problems with the existing draft that may not actually
be there.

> The draft makes use of "templated" URIs for some functions. IMO coding to support templated URIs is not significantly less onerous or complex than coding to support the link discovery that would be…

Good points. I would imagine that if made REST-ful, basically the
Server Information Service would be the major area needing
modifications.

> The draft combines the use of POSTs with Request bodies and querystrings. While not in contravention of RFC2616 it is pretty horrible and ugly IMO. You could achieve the same result by encoding the…

Just to be clear, is this a point about elegance or are there
technical aspects that cause it to fail (e.g., existing library
implementations that don't handle it properly)?

Either is response fine, I would just like to be sure on this thread
that we understand the technical tradeoffs at stake. That seems to be
orthogonal to the REST-ful vs. REST-like question, since the existing
draft could easily change whether parameters are specified in the body
or query-string.

Thanks!
Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Mar 2011 10:46:54 +0000

Richard, Jan,

On 22 Mar 2011, at 07:11, Richard Alimi wrote:

> agree.

I think the specification should permit relative URLs but I'm struggling a little to understand why there is any need to prohibit absolute URLs. 

> Do you envision a proxy sitting in front of an arbitrary ALTO
> administrative domain?

This is one of the values of a RESTful design IMO. The ALTO implementer is free to determine how they would like their ALTO implementation to make use of URLs and the choice of absolute or relative URLs is an implementation decision. If they choose relative URLs RFC3986 Section 5 provides the process to translate those relative URIs to an appropriate absolute URI.

One of the key tenets of RESTful design IMO is that one does not re-invent the underlying protocol components (e.g. HTTP behaviour & semantics) and therefore one is able to concentrate one's time on thinking about and designing the actual data and interactions with that data (state transitions) required to achieve one's aim rather than worrying about re-specifying the semantics of the underlying transport/protocol.

>  If it's in front of an arbitrary ALTO server,

If this is the use case (an arbitrary mod_proxy in front of an arbitrary ALTO server) then I'd say the problem is not ALTO's to solve. There are numerous examples of RESTful APIs and implementations in the wild of the Internet and within private networks and I haven't heard of them having to make restrictions with respect to absolute URLs to work around limitations of mod_proxy.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Mar 2011 12:00:28 +0000

Richard,

> opportunity for divergent implementations down the line.

I don't like the "compromise" approach. It would actually lead to divergence IMO because then you have the issue of implementation A implementing ALTO over the "REST-like" specification and implementation B following the REST-ful extensions and how to interoperate them. You actually cause more work and risk more pain in the end.

> experience as well.

Let's put my example of re-using a HTTP library to one side.

One of the primary purposes of RFCs IMO is to specify the necessary protocol details to enable someone who was not involved in the initial design decisions to implement the protocol. By re-specifying or prescribing HTTP sub-features you make the job of that person wishing to implement ALTO more difficult. If you just said "ALTO operates over HTTP" then an ALTO implementer knows they have to implement HTTP. As it stands an ALTO implementer does not know whether you are reusing HTTP as-is or whether you have changed the semantics of HTTP in some subtle way and therefore an ALTO implementer needs to do additional work to determine what the changes may be that is unnecessary if your claim that ALTO uses "standard HTTP" is correct.

You and others who have been involved in ALTO since the beginning may know that what you have specified just reuses HTTP but it is not clear to someone reading the specification for the first time with no prior involvement in ALTO that that is the case.

> Given that there are more than a few groups with

This misses the point, IMO.  Either ALTO reuses standard HTTP and therefore all the ALTO specification needs to say is that the ALTO data formats are carried over HTTP as specified in RFC2616 or ALTO does not use standard HTTP in which case it should clearly state that it does not operate over HTTP and that it is a new protocol based on HTTP but that the new protocol is divergent and the ALTO specification should state precisely what those divergences are.

If ALTO is just reusing HTTP and while working on ALTO things come to light in the HTTP specification that require clarification then the HTTPbis WG is already chartered to do that work.

> as opposed to problems with the existing draft that may not actually

The distinction is useful. If ALTO was RESTful we wouldn't need this discussion because none of the ambiguity from the current specification trying to profile HTTP would exist :-)

In terms of technical merits of RESTful, there are plenty of resources on the Internet discussing RESTful design and its merits along with examples of how refactoring applications to a RESTful design has lead to reduced code complexity, but I would state some of the primary motivators for me would be:

- Reduced coupling between client & server makes interoperability easier because server responses are self-describing.
- Therefore, client implementation is typically more straightforward as one only needs to understand the data model and not re-learn and potentially re-implement the underlying transport/protocol semantics.
- Reduced complexity as URIs actually tend to be simpler and more 'naturally' structured, which in turns leads to simpler code and easier extensibility.
- More resilient against post-deployment changes as resources are self-describing and so changes to server deployments do not require client-side code changes.
- Scalability as reuse of middleboxes such as proxies and CDNs is guaranteed.
 
> implementations that don't handle it properly)?

Using querystrings and Request bodies to pass data *at the same time* is inelegant but also a very bad design IMO. Pick one or the other but don't try and use both at the same time.

> draft could easily change whether parameters are specified in the body

IMO one of the fringe benefits of RESTful design is that it tends to naturally lead to more elegant design which in general makes the design simpler for someone to "pick up" and therefore less open to ambiguity.

In terms of tradeoffs, I think the advantage you have sticking as you are is that you have some early implementations. The disadvantage is as you come to extend ALTO over time you make (IMO) the job of doing so more cumbersome because you need to consider more than just the data you have and the interactions (state transfers) between representation of that data.

The advantage of a RESTful approach is you can spend your time only worrying about the data & its interactions, which at the end of the day is primary motivation for the ALTO WG existing and is also the bit of protocols/software design that's the most interesting/fun/satisfying (IMO). I believe it will be easier to extend the protocol later and you will ultimately end up with a much cleaner specification. The disadvantage is that you need to refactor your specification a bit, but that is not a big deal IMO because it is still an Internet-Draft so backwards compatibility with an existing RFC is not an issue.

Ben

---

From: Richard Alimi <[email-masked]>
Date: Tue, 22 Mar 2011 08:34:26 -0700

Hi Ben,

> I don't like the "compromise" approach. It would actually lead to divergence IMO because then you have the issue of implementation A implementing ALTO over the "REST-like" specification and impleme…

Agreed.

> The distinction is useful. If ALTO was RESTful we wouldn't need this discussion because none of the ambiguity from the current specification trying to profile HTTP would exist :-)

Maybe I am misunderstanding here. I think the existing draft makes
extremely basic usage of HTTP, in that it uses GET, POST, headers (and
in one case, trailers).  If you mean by profiling HTTP that we are
using only a subset of the features, then yes, thats true (and I think
it would be true of quite a few protocols out there).  However, if you
mean that we are using HTTP in a non-standard way, then I think I
disagree.  That said, it is certainly true that we could use more of
the features, e.g. content negotiation, within ALTO to accomplish what
we need.

In short, my understanding of the debate here is about how we use the
feature set of HTTP, as opposed to whether we use "standard HTTP" or
not.

Thus, I don't understand this statement: "Either ALTO reuses standard
HTTP and therefore all the ALTO specification needs to say is that the
ALTO data formats are carried over HTTP as specified in RFC2616 or
ALTO does not use standard HTTP ..."

In the former case, doesn't that leave it extremely underspecified?
We'd still need to state how the link document is created/formatted,
how content negotiation and MIME types are employed, etc.  Right?

> - Scalability as reuse of middleboxes such as proxies and CDNs is guaranteed.

I think that is a great list to serve as input to the discussion
(though we have already taken care to accomplish the first item for
other purposes - wished to allow redistribution amongst ALTO clients).
 I'd be interested to hear how others feel about these benefits as
well.

> IMO one of the fringe benefits of RESTful design is that it tends to naturally lead to more elegant design which in general makes the design simpler for someone to "pick up" and therefore less open…

I personally feel like we should be debating the technical merits
above, as opposed to elegance or inelegance. One could make similar
arguments about how the fully REST-ful design that we are talking
about is harder for someone to pick up, but I don't think that is
useful to debate here.  The technical merits that you listed above are
not subject to that, so it seems more useful to focus on those in this
thread.

> In terms of tradeoffs, I think the advantage you have sticking as you are is that you have some early implementations. The disadvantage is as you come to extend ALTO over time you make (IMO) the jo…

Good point. Personally (though I can't speak for other implementers),
I would rather get this right initially without feeling "attached" to
existing implementations. That said, since the encoding and overall
behavior of the protocol don't need to change (though the interactions
on the wire would), I don't think that existing implementations would
need to change all that much.

> The advantage of a RESTful approach is you can spend your time only worrying about the data & its interactions, which at the end of the day is primary motivation for the ALTO WG existing and is als…

Agree about getting this right the first time, and I agree about the
overall benefit (data vs interactions), though I think your list above
elucidates that in a much clearer way that can be discussed on this
thread or in the WG session.

Thanks,
Rich

---

From: Jan Medved <[email-masked]>
Date: Tue, 22 Mar 2011 11:15:09 -0700

On 3/22/11 12:38 AM, "Richard Alimi" <[email-masked]> wrote:

>>The current draft re-specifies or prescribes behaviour for particular
>>sub-features of HTTP. Without extensive analysis and comparison (which I
>>have not done) it is not easy to tell whether the "profile" specified in
>>the draft is compatible with HTTP/1.1 or contradicts RFC2616 in some
>>way. This places an unnecessary burden on implementers to do such
>>analysis and presents the risk that implementers may not be able to use
>>standard HTTP library code to implement ALTO clients and servers and
>>therefore may negate the obvious benefits of being able to reuse
>>standard library code to implement the underlying HTTP transport.
>>Furthermore it risks causing additional interoperability issues as it
>>opens up the potential for ambiguity of interpretation on how to
>>implement the ALTO "profile" of HTTP rather than letting implementers
>>(and the ALTO WG) concentrate on the data types and services you wish to
>>carry over HTTP. Compatibility with existing HTTP infrastructure
>>including proxies, cache
>> s and CDNs is also increased.
>>
>
The C, Java and Python protocol implementations (-06) that I know about
all use off-the-shelf open source HTTP and JSON libraries with no changes.

Thanks,
Jan

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Mar 2011 18:32:26 +0000

Richard,

I have changed the subject of this message as we have definitely diverged from discussing whether ALTO should follow RESTful design principles. Please see inline.

> the features, e.g. content negotiation, within ALTO to accomplish what

I am not trying to encourage ALTO to make use of more HTTP features but if you are going to say that ALTO operates over HTTP/1.1 then I don't think you should unnecessarily restrict the HTTP/1.1 feature set available to ALTO implementers.

If a particular ALTO implementation doesn't support specific features of HTTP/1.1 then it must fail/fallback in the manner specified in RFC2616. Likewise an ALTO implementation must be free to attempt to make use of any valid HTTP/1.1 feature. Otherwise you are not using HTTP/1.1 you are using some specific sub-set of HTTP/1.1 and you must IMO explicitly call out exactly what features you are using and what features you are explicitly prohibiting.

From the discussion we've been having I get the impression that you believe that any description of HTTP in the ALTO protocol draft basically constitutes "implementation guidance" and therefore does not introduce ambiguity for implementers. Whereas I maintain that the ALTO draft unnecessarily attempts to force use of certain HTTP sub-features over others and therefore introduces ambiguity for an implementer.

Let me provide some examples from a quick scan of draft-ietf-alto-protocol-07, there are probably others.

1) alto-protocol-07 contains normative descriptions of the allowed Response syntax which imply through the presence of a "Content-Length: <BodyLength>" header that chunked transfer-encoding is not permitted by the ALTO protocol but alto-protocol-07 does not explicitly state that chunked transfer-encoding is prohibited. So is an ALTO response that makes use of chunked transfer-encoding a valid response or not? As an implementer it is not clear to me whether it is.

I would argue including HTTP headers as part of defining what is a valid response is unnecessary and the specification should simply state that the ALTO server may return any valid HTTP headers. I think it's OK to include example headers in example responses but not to unnecessarily restrict the syntax of responses.

2) alto-protcol-07 section 7.6.2 states "Cookies MUST NOT be used." So is an ALTO Request/Response containing a Cookie/Set-Cookie header (respectively) an invalid ALTO Request/Response? If an ALTO server is on alto.example.com and example.com has previously set a cookie on a User-Agent that also contains an ALTO implementation then I would argue there is no need to unnecessarily restrict the User-Agent behaviour rather than just stating that cookies have no specific semantics within the context of the ALTO protocol and leaving it as an implementation/configuration decision for the client? 

3) alto-protocol-07 section 7.6.3 states "If a Response generated by the ALTO Server is not cachable, the ALTO Server MUST specify the "Cache-Control: no-cache" HTTP Header"

While "Cache-Control: no-cache" is one possible way to express that semantic, it is not the only one allowed by HTTP/1.1. Does that mean an implementer is free to interpret an ALTO response without "Cache-Control: no-cache" as being cacheable even if it has an Expires header stating it isn't? I would argue there's no need top mandate the use of "Cache-Control: no-cache", so why unnecessarily restrict an ALTO implementation?

IMO the examples above are only a sample but demonstrate that the draft's attempt to provide implementation guidance doesn't actually add much, if any, additional value over just stating that ALTO reuses HTTP but including it in the normative text does introduce ambiguity for implementers. If there is a strong desire to still include the "implementation guidance" then it should be clearly marked as non-normative IMO.

Ben

---

From: Richard Alimi <[email-masked]>
Date: Tue, 22 Mar 2011 12:11:20 -0700

Hi Ben,

> From the discussion we've been having I get the impression that you believe that any description of HTTP in the ALTO protocol draft basically constitutes "implementation guidance" and therefore doe…

Thank you for clarifying what you mean here.  This is good feedback
that will certainly help the draft.

The intent of the draft was not exclude all features of HTTP/1.1
except the ones called out explicitly. Rather, it was the opposite:
the intent was to indicate the features use to allow an ALTO Server to
understand which message it was receiving and how it should be
interpreted. We can fix the wording to make it clear that we are not
unnecessarily excluding all other features of HTTP by default.

> I would argue including HTTP headers as part of defining what is a valid response is unnecessary and the specification should simply state that the ALTO server may return any valid HTTP headers. I…

The examples used Content-Length, but those should not be taken to be
normative. The statement "The Content-Length header MUST follow the
standard rules defined in HTTP 1.1" was intended to only apply if it
were used, but I'd agree that we may be overspecifying to the point of
making it unclear it is not the only permitted way of specifying the
request. That should be fixed.

> 2) alto-protcol-07 section 7.6.2 states "Cookies MUST NOT be used." So is an ALTO Request/Response containing a Cookie/Set-Cookie header (respectively) an invalid ALTO Request/Response? If an ALTO…

Indicating that such headers should be ignored is fine with me. (The
intent was from Slide 33 of
http://www.ietf.org/proceedings/76/slides/saag-2.pdf, and I agree the
draft is currently overrestrictive in implementing that.)

> While "Cache-Control: no-cache" is one possible way to express that semantic, it is not the only one allowed by HTTP/1.1. Does that mean an implementer is free to interpret an ALTO response without…

The overall intent was to ensure that cacheability was included on
every response (slide 30 of the same slide deck). Again, I'd agree
this overrestrictive as currently stated.

> IMO the examples above are only a sample but demonstrate that the draft's attempt to provide implementation guidance doesn't actually add much, if any, additional value over just stating that ALTO…

We appreciate the comments here. Occurrences of this should be fixed
in the draft, and I've made a note to go through the draft again to
see if there are other similar occurrences in other sections. Thank
you for splitting it out from the REST-ful vs. REST-like discussion (I
agree it is orthogonal).

Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Mar 2011 19:29:07 +0000

Richard,

> unnecessarily excluding all other features of HTTP by default.

Thanks. What I'd propose is that you hold fire on making any clarifying changes to the draft until after the WG has resolved whether it would like to refactor the specification to be RESTful or not because if we go down the RESTful route I believe many of my concerns with the current draft will naturally "evaporate" either as part of the refactoring itself or they can be tackled as part of any restructuring of the draft resulting from moving to a RESTful design approach.

If the WG decides not to refactor and leave the ALTO protocol "as-is" I can work with you and your co-authors to clean up the draft and tackle my concerns with the current draft.

Ben

---

From: Richard Alimi <[email-masked]>
Date: Tue, 22 Mar 2011 12:31:33 -0700

> If the WG decides not to refactor and leave the ALTO protocol "as-is" I can work with you and your co-authors to clean up the draft and tackle my concerns with the current draft.

Agree. Thanks again!

Rich

---

From: Jan Medved <[email-masked]>
Date: Tue, 22 Mar 2011 13:09:52 -0700

On 3/22/11 3:46 AM, "Ben Niven-Jenkins" <[email-masked]> wrote:

>If this is the use case (an arbitrary mod_proxy in front of an arbitrary
>ALTO server) then I'd say the problem is not ALTO's to solve. There are
>numerous examples of RESTful APIs and implementations in the wild of the
>Internet and within private networks and I haven't heard of them having
>to make restrictions with respect to absolute URLs to work around
>limitations of mod_proxy.
>
True, but these mostly are use cases where there is a single instance of a
service. Whatever we do here, we need make sure that a client can use
different ALTO Server instances, and different ALTO Server
implementations, in the same way.

/Jan

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 22 Mar 2011 20:58:10 +0000

Jan,

> implementations, in the same way.

My apologies but I don't really follow. Would it be possible for you to provide an outline description of a deployment scenario where mod_proxy would break an ALTO server implementation that returned absolute URLs but where other services running over HTTP that made use of absolute URLs would not break?

Thanks
Ben

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 25 Mar 2011 15:53:55 +0000

Vijay,

Thanks, something to read for the way to Prague. :)

See you there

  Martin

> Vijay K. Gurbani
> Sent: Tuesday, March 15, 2011 3:19 PM
> To: [email-masked]
> Subject: Re: [alto] ALTO protocol: REST-ful vs. REST-like
>