Sorry if there is already a nice list someplace, but I've been trying make a
list of solid blogs that deal primarily with REST.  So far, these are my
favorites:

http://mamund.com/blog
http://www.subbu.org
http://roy.gbiv.com/untangled/tag/rest
http://thisweekinrest.wordpress.com

so, yeah...kind of a sparse list =D

(also...is there an faq or etiquette guide anywhere?  is this sort of post cool?
...and is it okay to ask for feedback on my own blog posts?  (aka pimp my blog))

On Sep 30, 2010, at 11:46 PM, raypolk55 wrote:

> Sorry if there is already a nice list someplace, but I've been trying make a
list of solid blogs that deal primarily with REST.  So far, these are my
favorites:
>
> http://mamund.com/blog
> http://www.subbu.org
> http://roy.gbiv.com/untangled/tag/rest
> http://thisweekinrest.wordpress.com

*the classic* http://www.markbaker.ca/blog

Stefan's
http://www.innoq.com/blog/st/

Mine :-)
http://www.nordsc.com/blog

And defiinitely more, but I have bad connection here.

Jan



>
> so, yeah...kind of a sparse list =D
>
> (also...is there an faq or etiquette guide anywhere?  is this sort of post
cool?  ...and is it okay to ask for feedback on my own blog posts?  (aka pimp my
blog))
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

likewise..

-------- Original Message --------
Subject: Fwd: [apps-discuss] Fwd: WG Review: Web Security (websec)
Resent-Date: Sat, 02 Oct 2010 01:38:30 +0000
Resent-From: ietf-http-wg@...
Date: Sat, 2 Oct 2010 11:37:45 +1000
From: Mark Nottingham <mnot@...>
To: HTTP Working Group <ietf-http-wg@...>
References: <4CA22A4F.3080502@...>

In case you haven't seen it...


Begin forwarded message:

> From: Peter Saint-Andre <stpeter@...>
> Date: 29 September 2010 3:47:59 AM AEST
> To: "apps-discuss@..." <apps-discuss@...>
> Subject: [apps-discuss] Fwd: WG Review: Web Security (websec)
>
> FYI.
>
> -------- Original Message --------
> Subject: WG Review: Web Security (websec)
> Date: Tue, 28 Sep 2010 10:15:06 -0700 (PDT)
> From: IESG Secretary <iesg-secretary@...>
> Reply-To: iesg@...
> To: ietf-announce@...
> CC: hasmat@...
>
> A new IETF working group has been proposed in the Applications Area.  The
> IESG has not made any determination as yet. The following draft charter
> was submitted, and is provided for informational purposes only. Please
> send your comments to the IESG mailing list (iesg@...) by Tuesday,
> October 5, 2010.
>
> Web Security (websec)
> ---------------------------------------------
> Status: Proposed Working Group
> Last updated: 2010-09-23
>
> Chairs(s)
>   Tobias Gondrom <tobias.gondrom@...>
>
> Applications Area Directors:
>   Alexey Melnikov <alexey.melnikov@...>
>   Peter Saint-Andre <stpeter@...>
>
> Applications Area Advisor:
>   Peter Saint-Andre <stpeter@...>
>
> Security Area Advisor:
>   Sean Turner <turners@...>
>
> Mailing Lists:
>  General Discussion: hasmat@...
>  To Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>
>  Archive: <http://www.ietf.org/mail-archive/web/hasmat/>
>  [to be changed to websec@... if approved]
>
> Problem Statement
>
> Although modern Web applications are built on top of HTTP, they provide
> rich functionality and have requirements beyond the original vision of
> static web pages.  HTTP, and the applications built on it, have evolved
> organically.  Over the past few years, we have seen a proliferation of
> AJAX-based web applications (AJAX being shorthand for asynchronous
> JavaScript and XML), as well as Rich Internet Applications (RIAs), based
> on so-called Web 2.0 technologies.  These applications bring both
> luscious eye-candy and convenient functionality, e.g. social networking,
> to their users, making them quite compelling.  At the same time, we are
> seeing an increase in attacks against these applications and their
> underlying technologies.
>
> The list of attacks is long and includes Cross-Site-Request Forgery
> (CSRF)-based attacks, content-sniffing, cross-site-scripting (XSS)
> attacks, attacks against browsers supporting anti-XSS policies,
> clickjacking attacks, malvertising attacks, as well as man-in-the-middle
> (MITM) attacks against "secure" (e.g. Transport Layer Security
> (TLS/SSL)-based) web sites along with distribution of the tools to carry
> out such attacks (e.g. sslstrip).
>
> Objectives and Scope
>
> With the arrival of new attacks the introduction of new web security
> indicators, security techniques, and policy communication mechanisms
> have sprinkled throughout the various layers of the Web and HTTP.
>
> The goal of this working group is to compose an overall "problem
> statement and requirements" document derived from surveying the
> issues outlined in the above section ([1] provides a starting point).
> The requirements guiding the work will be taken from the Web
> application and Web security communities.  The scope of this document
> is HTTP applications security, but does not include HTTP authentication,
> nor internals of transport security which are addressed by other working
> groups (although it may make reference to transport security as an
> available security "primitive").  See the "Out of Scope" section, below.
>
> Additionally, the WG will standardize a small number of selected
> specifications that have proven to improve security of Internet
> Web applications.  Initial work will be the following topics:
>
>  - Same origin policy, as discussed in draft-abarth-origin
>    (see also Appendices A and B, below)
>
>  - HTTP Strict transport security, as discussed in
>    draft-hodges-strict-transport-sec
>
>  - Media type sniffing, as discussed in draft-abarth-mime-sniff
>
> This working group will work closely with IETF Apps Area WGs (such as
> HYBI, HTTPstate, and HTTPbis), as well as appropriate W3C working
> group(s) (e.g. HTML, WebApps).
>
> Out of Scope
>
> As noted in the objectives and scope (above), this working group's
> scope does not include working on HTTP Authentication nor underlying
> transport (secure or not) topics. So, for example, these items are
> out-of-scope for this WG:
>
>  - Replacements for BASIC and DIGEST authentication
>
>  - New transports (e.g. SCTP and the like)
>
> Deliverables
>
> 1. A document illustrating the security problems Web applications are
> facing and listing design requirements.  This document shall be
> Informational.
>
> 2. A selected set of technical specifications documenting deployed
> HTTP-based Web security solutions. These documents shall be Standards
> Track.
>
> Goals and Milestones
>
> Oct 2010    Submit "HTTP Application Security Problem Statement and
>           Requirements" as initial WG item.
>
> Oct 2010    Submit "Media Type Sniffing" as initial WG item.
>
> Oct 2010    Submit "Web Origin Concept" as initial WG item.
>
> Oct 2010    Submit "Strict Transport Security" as initial WG item.
>
> Feb 2011    Submit "HTTP Application Security Problem Statement and
>           Requirements" to the IESG for consideration as an
>           Informational RFC.
>
> Mar 2011    Submit "Media Type Sniffing" to the IESG for consideration
>           as a Standards Track RFC.
>
> Mar 2011    Submit "Web Origin Concept" to the IESG for consideration as
>           a Standards Track RFC.
>
> Mar 2011    Submit "Strict Transport Security" to the IESG for
>           consideration as a Standards Track RFC.
>
> Apr 2011    Possible re-chartering
>
> References
>
> [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy
> Framework", W2SP position paper, 2010.
> http://w2spconf.com/2010/papers/p11.pdf
>
> Appendices
>
> A. Relationship between origin work in IETF WebSec and W3C HTML WG
>
> draft-abarth-origin defines the nuts-and-bolts of working with
> origins (computing them from URIs, comparing them to each other, etc).
> HTML5 defines HTML-specific usage of origins.  For example, when
> making an HTTP request, HTML5 defines how to compute which origin
> among all the origins rendering HTML is the one responsible for making
> the request.  draft-abarth-origin then takes that origin, serializes
> it to a string, and shoves it in a header.
>
> B. Origin work may yield two specifications
>
> There also seems to be demand for a document that describes the
> same-origin security model overall.  However, it seems like that
> document ought to be more informative rather than normative. The
> working group may split draft-abarth-origin into separate informative
> and standards track specifications, the former describing same-origin
> security model, and the latter specifying the nuts-and-bolts of working
> with origins (computing them from URLs, comparing them to each other,
> etc).
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@...
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/

No, of course I didn't just send that, but we now have some idea of
Yahoo's latency -- which only justifies my decision to re-send instead
of waiting, despite the duplicate messages now trickling in.  I think
that's all of 'em, though...

-Eric

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 9/24/2010 8:37 PM, Eric J. Bowman wrote:
> Kris Zyp wrote:
>>
>> I guess maybe I misunderstood what you meant by processing model. If
>> it is defined such it is not related to the expected data structures,
>> hyperlink mechanisms and available relations, than it is indeed
>> orthogonal to a schema. That's fine with me, sorry for any confusion.
>>
>
> What I mean is, you can't recommend doing this:
>
> Content-Type: application/json;
> profile=http://json.com/my-hyper-schema
>
> Because when I look at the IANA registry, I see that application/json
> maps to RFC 4627, which only lists one optional parameter, charset. I
> see no definition of any profile parameter. The usage you are
> recommending is not self-descriptive, because it is not supported by RFC
> 4627.
>
> One possible processing model for XHTML documents is text/plain, another
> is text/html, and another is application/xhtml+xml -- please see RFC
> 3236 as an example of how a media type registration is the proper place
> to define such usage. RFC 3236 doesn't extend the definition of profile
> to text/html, text/plain, or even application/xml -- this would be out-
> of-scope.
>
> If a standard comes along which registers application/foo+json, it is
> up to that MIME registration to define the usage of a profile parameter.
> Such a definition shouldn't have to worry about conflicting with some
> other use of that syntax being forced on it by an unrelated spec, in
> particular a schema spec which may have nothing whatever to do with the
> schema (or BNF notation) being used to describe application/foo+json.

Yes, that makes sense, I'll update the text for the next draft to try
to have more appropriate language.

>
> This usage is part of the processing model defined by the media type
> identifier, it is not appropriate for a schema language to define such
> usage for anything beyond, in this case, application/schema+json --
> your media type registration for that identifier doesn't make sense, as
> it doesn't define 'schema' or 'schema.items' and omits any mention of
> the 'profile' parameter (again, see RFC 3236).
>
> Don't get me wrong, I'm in favor of +json, I'm just giving the same
> feedback that both schema+json and senml+json have gotten -- the right
> way to do this is to first change RFC 4288, then RFC 4627:
>
> http://www.ietf.org/mail-archive/web/ietf-types/current/msg01062.html
>
> Otherwise, I don't see approval of either I-D until that issue is
> settled or their associated identifier syntax is changed. But then
> again, maybe it will be anyway, I don't know -- all I do know is that
> no +json identifier has yet made it into the IANA registry, therefore no
> +json identifier is currently self-descriptive; and that it is not self-
> descriptive to use a profile parameter in conjunction with any media
> type identifier unless that identifier defines a profile parameter.

- From that thread, it sounded like everyone was in favor of making the
updates. I wonder if that is being done by someone...

- --
Kris Zyp
SitePen
(503) 806-1841
http://sitepen.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkydcYIACgkQ9VpNnHc4zAyDEACfSl9koe9GiSIG4Vj4bIFF9qip
SqcAn02wFDwZw7pljiIb+8pdIeVgFevm
=BJaB
-----END PGP SIGNATURE-----

Glenn Block wrote:
>
> Assuming the system uses one or more custom media types would the
> recommendation be that those types be registered with IANA?
>

It's more than a recommendation, it's an absolute requirement, as
having a network-defined (IP defines MIME defines the IANA registry)
identifier is the fundamental difference between a uniform interface
(network-defined) and a plain old HTTP interface (library-defined).

The dichotomy between resource and representation is realized by
exposing the sender's processing intent in a header, allowing that
intent to be decoupled from the data format.  Just like Gopher and HTTP,
not at all like FTP.

The essence of the REST style is that this decoupling must be based on
a network-defined value for that header.  Gopher messaging over IP is
not self-descriptive because it defines its own identifier syntax,
instead of using the agreed-upon standard for self-descriptive IP
network message tagging and bagging, the Internet Media Type (RFC 2048).

(Yes, I realize this contradicts what I've said before, Nathan's
feedback has made my position even more strict than it was.  Don't
forget that to some extent, REST is an ex-post-facto explanation of the
decision to extend MIME beyond e-mail to begin with, by encapsulating
the rationale and benefits of this decision within a constraint.)

In order to meet REST's definition of what makes an interface uniform,
the media type must be a media type, where IP is concerned.  If the
identifier in Content-Type isn't registered, then it isn't an Internet
Media Type, by the definition of media type, therefore it's *just a
string*, even if it's a URI, regardless of its syntax.

Internet Media Types are self-descriptive *because* they're Internet
Media Types, i.e. registered.  Strings are not Internet Media Types,
therefore they are not self-descriptive, therefore not standardized,
therefore not uniform, therefore library-based instead of network-
based, therefore not remotely the same style as REST.

-Eric

>
> Internet Media Types are self-descriptive *because* they're Internet
> Media Types, i.e. registered.  Strings are not Internet Media Types,
> therefore they are not self-descriptive, therefore not standardized,
> therefore not uniform, therefore library-based instead of network-
> based, therefore not remotely the same style as REST.
>

We can discuss the theoretical importance of this for proprietary
systems until the cows come home, of course, provided that we agree on
the definition of "media type" vs. "data type + identifier string".
But the ramifications of the constraint lead to this advice:

"[W]orking with the community and discussing the proposed media type
with experts on the ietf-types list in order to create something that
can be registered will probably lead to better results.  There are many
people who are happy to help create solutions for problems, and
standardization bodies + would-be communities that will gladly assist
in creating a standardized solution."

http://tech.groups.yahoo.com/group/rest-discuss/message/16653

There's nothing wrong with some outside review, even for proprietary
solutions, of any proposed media type (there's no such thing as an
unregistered media type).  Even if the decision is made to continue
sending a string in Content-Type in lieu of a media type, surely some
insight from experts in media type design would be of use.

-Eric

Darrel Miller wrote:
>
> Would you consider this list to be an appropriate venue to solicit
> feedback about potential media-types, before asking on the IETF types
> list?
>

Absolutely!  I think that would lead to much better conversations on
both lists, resulting in better, more re-usable media types for everyone
to choose from (instead of one media type per dialect as per Nathan),
encompassing as many problem domains as are already using unregistered
identifiers as solutions.

-Eric

Glenn Block wrote:
>
> I do think regardless having a body or some lore on media type design
> would be really valuable.
>

I think there is one -- every media type (i.e. registered) links to a
media type description.  Each one (where one exists) describes a
processing model that was approved by IANA at one time or another, as
being exactly what is meant by "media type".  The demo I posted uses a
dozen different media types.  Reading all those documents takes a day,
but provides much enlightenment on approved media type design.

>
> Back to the question at hand, I find myself struggling with what I
> lose if the type is not registered. Saying it must be registered
> implies some big loss. For a proprietary system where I control who
> the clients are, or I use code on-demand to deploy the user-agent
> code, why do I care if the type is registered or not?
>
> Can you point out exactly what I lose in such a system if I don't
> register it.
>

No, I can't, only the system designer is in a position to judge what's
best for the system being designed.  I can point out that you're asking
the wrong question, though...  the proper questions are what properties
are you seeking to induce, and what constraints do you apply to achieve
those properties?  From REST Chapter 6.5:

"Why is this important?  Because it differentiates a system where
network intermediaries can be effective agents from a system where they
can be, at most, routers."

If you honestly don't care about traversing network boundaries, or re-
use by intermediaries if you do, then I can think of at least three
REST constraints off the top of my head which are irrelevant to your
needs -- IOW, why choose REST as an architectural style if it's
fundamentally inappropriate to your design goals?

Everyone keeps asking if it's OK to ignore the uniform interface in
situations where the uniform interface is irrelevant to their needs...
sure, just don't call the result REST, or obsess over it not being REST.

The first three chapters of Roy's thesis lay out a terminology and a
rationale for deriving networked application architectures (including
but not limited to hypermedia applications).  The next two chapters lay
out the design concerns of the REST style, and the methodology used to
derive it based on the terminology and rationale from Chapters 1-3.

If your concerns are different, then following Roy's methodology won't
lead you to REST, but to some other style -- all that matters is that it
leads you to an architectural style that's appropriate for your system.
You can name it whatever you want, because an architectural style is
really just a named set of interdependent constraints -- which is why
omitting any constraint results in a different style.

Start with the null style (as described in Chapter 5).  Apply the subset
of architectural constraints which result in the properties you seek to
induce (as described in Chapter 3).  Ignore the subset of architectural
constraints whose properties don't advance you to your goal.  The result
is an architectural style appropriate to serve as a design guideline
when modeling and implementing your system.

If that style doesn't require media types, so be it, but the REST style
sure does -- most intermediaries only care about a limited subset of
media types (meaning registered).  Which is why self-descriptive
messaging is essential to the REST style -- it allows traversing of
network boundaries (not guaranteed without using media types, could be
seen as tunneling) while enabling intermediaries to act as intelligent
agents (participate in the communication beyond being routers).

Saying you don't care about those properties, means you have no need
for the full set of REST constraints, means you have some other set of
constraints, which isn't the same set of constraints defined by the term
REST.  Which is not to say you shouldn't follow Roy's thesis, only that
you can't *expect* that methodology to result in the same architectural
style Roy defines for purposes you state aren't relevant to your
system's needs, anyway...

-Eric

Most OS package-management systems have GUIs these days, and the back-
ends to these systems mostly use wget (mostly to FTP sites) as user
agent.  What URIs to have wget fetch, are determined by the text
configuration files (patches, prerequisite packages, options etc.).

If a URI is unavailable, an alternate is selected and processing
continues -- the user selecting these application state transitions
expressed as URIs, is the installer process (i.e. ports/pkgsrc), no
human involved except to select options and initiate the installer (via
hypertext API of course).

The media type of each patch tells us the encoding of its tarball, not
that when extracted it's part of a numbered set of patches for some
other tarball.  This processing model may be standards-worthy -- as a
multipart media type which allows each tarball to be a set of alternate
links in order of preference (or via net heuristic), and establishes
the order in which the patches are to be applied.

Just a thought -- while a RESTful-m2m fork of pkgsrc would be fun, I
hardly have the time.  Instead of downloading a tree of stub files, the
installer dereferences the package manifest of the requested package
from some host, the representation is this new multipart media type,
which defines the sender's intended processing model -- guiding the
installer's use of wget as its agent, extracting and patching together
the returned tarballs.

-Eric

Glenn,

On Oct 4, 2010, at 4:39 AM, Glenn Block wrote:

>
>
> I agree that having some place where such discussions can take place would be
valuable. I am not sure this is the right list or if there should be a list
formed specifically for that purpose in order to make it more useful. I do think
regardless having a body or some lore on media type design would be really
valuable.
>
> Back to the question at hand, I find myself struggling with what I lose if the
type is not registered.

You might call it desirable, but it is certainly not required to register media
types with IANA to have a working system. There are several non registered types
out there today that are being used successfully - and there are also a bunch of
registered types that are not being used widely (or at all).

What matters is that you are able to find the specification and, maybe more
importantly, the community around it. Usually the spec alone is not sufficient
to grasp the type, eh?

Jan



> Saying it must be registered implies some big loss. For a proprietary system
where I control who the clients are, or I use code on-demand to deploy the
user-agent code, why do I care if the type is registered or not?
>
> Can you point out exactly what I lose in such a system if I don't register it.
>
> On Sun, Oct 3, 2010 at 7:27 PM, Eric J. Bowman <eric@...> wrote:
> Darrel Miller wrote:
> >
> > Would you consider this list to be an appropriate venue to solicit
> > feedback about potential media-types, before asking on the IETF types
> > list?
> >
>
> Absolutely!  I think that would lead to much better conversations on
> both lists, resulting in better, more re-usable media types for everyone
> to choose from (instead of one media type per dialect as per Nathan),
> encompassing as many problem domains as are already using unregistered
> identifiers as solutions.
>
> -Eric
>
>
>
>

Glenn Block wrote:
>
> But (and this is the rub) on the other side of the discussion I am
> seeing folks arguing against the premise that registration with IANA
> is indeed required for conformance to the uniform interface.
>

None of those arguments have explained why Roy didn't mean exactly what
he said (why should he need to repeat himself):

"Self-descriptive means that the type is registered and the registry
points to a specification and the specification explains how to process
the data according to [sender] intent."

http://tech.groups.yahoo.com/group/rest-discuss/message/6594
http://tech.groups.yahoo.com/group/rest-discuss/message/6615

Which is the same conclusion to be drawn from the thesis, absent that
statement, with or without the mime-respect note.  The constraint in
question is the embodiment of the decision to expand MIME from e-mail
to become *the* tagging-and-bagging spec for IP network protocols.
Chapter 6 extensively covers the topic of REST mismatches in HTTP,
without mentioning the IANA registry...

There is simply no argument to be made against this, which doesn't
amount to advocating against standardization or against following the
specs as they're written -- both of which are against the point of REST.
The definition of self-descriptive is not "has Content-Type," it is
"Content-Type contains a media type;" the definition of media type is
not "any string sent in Content-Type," but "strings specified in the
IANA registry" -- when we're talking about HTTP and Internet Protocol,
respectively; application/foo+xml is not a media type, it's just a
string.

REST clearly defines media type as representation metadata as per RFC
2048, which clearly states "A registration process is needed, however,
to ensure that the set of such values is developed in an orderly,
well-specified, and public manner."  If Roy didn't mean to constrain
the value of Content-Type to a registered subset of publicly well-
specified media types developed in an orderly manner, then why does he
even mention media types let alone refer to RFC 2048, and why does RFC
2616 discourage the use of even the allowable x. syntax?  And, why does
this document:

http://www.ietf.org/id/draft-masinter-mime-web-info-00.txt

Even exist as an RFC process with one stated goal being to edit AWWW to
go from not mentioning media types, to explaining why they're critical?
Because the TAG has decided to move *away* from REST?  ;-)  Seriously,
how is anything I've been saying in conflict with that document (they
even mention poor ol' Gopher)?  That's the TAG doubling down on the
IANA registry...

Where are the voices of protest against that, which are so quick to
condemn my statements as absurd?  G'head, let the TAG have it, that's
www-tag@..., if they're not following REST surely someone ought to
let them know?  Their goals are congruous with REST, so if their actions
aren't RESTful how will they achieve those goals if nobody steps up and
educates them as to their folly?  Does the following passage not
enumerate some of REST's key design goals?

"We need a clear direction on how to make the web more reliable, not
less.  We need a realistic transition plan from the unreliable web to
the more reliable one.  Part of this is to encourage senders (web
servers) to mean what they say, and encourage recipients (browsers) to
give preference to what the senders are sending... [We should] encourage
behavior which, on the one hand, continues to work with the already
deployed infrastructure (of servers, browsers, and intermediaries), but
which advice, if followed, also improves the operability, reliability
and security of the web."

By which the TAG clearly means _use media types_ instead of strings in
your Content-Type headers... not at all coincidentally, just as REST
prescribes!  Something tells me not to expect Roy to post any criticism
of the TAG's increasing focus on media types as the key to reliability,
interoperability and security at Internet scale.  Kind of exactly what
I've been saying on this list for the past year now, to the extent of
editing the thesis, without rebuke from Roy...

This _still_ shouldn't be controversial at all, it's exactly what the
specs say, which is exactly the standardization that is meant by
"uniform" in REST.  Nobody has provided any logical explanation as to
how "uniform" could possibly mean "unstandardized random strings
instead of media types" by *any* interpretation of REST or the
standards it refers to, or why it's irrelevant to Web architecture for
uniform to actually mean ad-hoc.

What is the sender intent here?  Is this a media type by virtue of
being a standard linked to in a Content-Type header?

Content-Type: http://www.w3.org/TR/xhtml1/

HTML rendering or XML parsing?  That isn't a media type, it's just a
string.  Yeah, it's a URI that points to a standardized data type, but
in terms of defining sender intent it's beyond useless, because that's
what media types do, and a URI is not a media type, not even this one:

Content-Type: http://www.ietf.org/rfc/rfc3023.txt

That is *not* self-descriptive because URIs are *not* media types by
virtue of being sent in Content-Type, and neither is application/foo+
xml.  The only things that are media types, are listed in the IANA
registry, by definition.  Anything else is _just a string_ and does not
describe sender intent, including and especially application/rss+xml,
the use of which is a _blatant_ violation of RFC 2048 and _still_
requires introspection to determine intent -- how is any identifier
which fails to describe sender intent, self-descriptive of that intent?

Practicing REST on the Web means you MUST use media types.  If there's
one hard-and-fast rule which always holds true, it's this one, and it's
fundamental to the whole concept of REST's uniform interface.

(I dream of the day when that last statement garners a single +1.)

-Eric

Glenn Block wrote:
> For a proprietary system where I control who the clients are, or I use
> code on-demand to deploy the user-agent code, why do I care if the type is
> registered or not?
>
> Can you point out exactly what I lose in such a system if I don't register
> it.

You don't loose anything that wasn't already lost by the system being
un-RESTful, constraint number 1:

"The first constraints added to our hybrid style are those of the
client-server architectural style, described in Section 3.4.1.
Separation of concerns is the principle behind the client-server
constraints. ... the separation allows the components to evolve
independently, thus supporting the Internet-scale requirement of
multiple organizational domains."

Maybe I completely missunderstand something but afaict that certainly
doesn't describe "a proprietary system where I control who the clients
are, or I use code on-demand to deploy the user-agent code"

Best,

Nathan

On Mon, Oct 4, 2010 at 9:20 AM, Eric J. Bowman <eric@...> wrote:
>
> Which is the same conclusion to be drawn from the thesis, absent that
> statement, with or without the mime-respect note.  The constraint in
> question is the embodiment of the decision to expand MIME from e-mail
> to become *the* tagging-and-bagging spec for IP network protocols.
> Chapter 6 extensively covers the topic of REST mismatches in HTTP,
> without mentioning the IANA registry...

Why would that be a mismatch?

You're missing the point; the argument has been that centralised
registration is _not a requirement_ for REST. Shared understanding is
the requirement, which can be achieved via other means than a central
registry.

Interestingly; HTTP doesn't actually *require* use of registered type
identifiers which we know because of the specific wording in 2616
where non-registered identifiers are merely "discouraged" . If formal
IANA registration was a fundamental requirement to establish shared
understanding, presumably _that_ should have been raised as a
mismatch? Oops.


> REST clearly defines media type as representation metadata as per RFC
> 2048, which clearly states "A registration process is needed, however,
> to ensure that the set of such values is developed in an orderly,
> well-specified, and public manner."

That is anything but "hard science". It's completely subjective and it
isn't backed up by any empirical evidence.

It also happens to be being ignored (in the real world) by people
building systems that - obviously by some act of the devil - actually
work ok; with intermediaries (i.e. caches and proxies) leveraging the
self-descriptiveness of messages too. Shocking.

>  If Roy didn't mean to constrain
> the value of Content-Type to a registered subset of publicly well-
> specified media types developed in an orderly manner, then why does he
> even mention media types let alone refer to RFC 2048

I don't know why the style references an implementation detail of the
web. That does seem a bit odd.

Cheers,
Mike

Mike Kelly wrote:
> On Mon, Oct 4, 2010 at 9:20 AM, Eric J. Bowman <eric@...> wrote:
>> Which is the same conclusion to be drawn from the thesis, absent that
>> statement, with or without the mime-respect note.  The constraint in
>> question is the embodiment of the decision to expand MIME from e-mail
>> to become *the* tagging-and-bagging spec for IP network protocols.
>> Chapter 6 extensively covers the topic of REST mismatches in HTTP,
>> without mentioning the IANA registry...
>
> Why would that be a mismatch?
>
> You're missing the point; the argument has been that centralised
> registration is _not a requirement_ for REST. Shared understanding is
> the requirement, which can be achieved via other means than a central
> registry.

Shared understanding is the requirement, so given a temporally varying
set of clients, servers and intermediaries, and a constant transfer
protocol, then the only way to achieve a shared understanding of
anything, from messages through to the type label of the content being
transferred, is to have it defined by the constant, namely the transfer
protocol.

That is to say, three servers and six clients all sharing knowledge that
a specific content type label exists, and sharing an understanding of
content typed with that label does not constitute shared understanding
at an architectural level.

To illustrate simply include another set of clients and servers which
also share knowledge that a specific content type label exists, and
understand content typed with the label, but use the same content type
label as our original set; this is a conflict, a name collision if you
will, and proves that understanding is not shared at an architectural,
or even transfer protocol, level

The only way to prevent this conflict at an architectural or transfer
protocol level is to define a set of content type labels and a method
for components to share which of the set they understand, for instance
the Content-Type and Accept headers in the hypertext transfer protocol.

In order to understand content typed with a specific label, then a
specification for that content type must be known, and given that some
content type outwith the set could also share the same name, or that two
content types within the set could share similar ambiguous names, then
the only way to prevent conflict here is to store a reference to the
content type specification along with the label for that content type,
within the defined set.

So, the only way to meet this requirement of shared understanding is to
have a defined set of content type label + content type specification
pairs at architectural or transfer protocol level. That set may consist
of only one, or may be a fixed set, or may be a varying set.

If it's a varying set then some means of adding and removing content
type label + content specification pairs is needed - typically we refer
to this a registry with registration process.

Thus we need a registry at the architectural level, and at transfer
protocol level.

Bringing it back to the real world, *the shared understanding of content
type labels already exists* at an architectural level, we call the
labels "Internet Media Types", they have a registry at IANA, and a well
defined registration process, these aren't just transfer protocol
specific, they are a shared understanding at the Internet Layer, which
is two layers below any transfer protocol.

This is why the transfer protocols you use on a daily basis, like SMTP,
FTP and HTTP all use internet media types.

In other words, to meet the shared understanding constraint and not use
IANA registered media types you would not only have to go lower than
(HTTP/DNS etc), but you'd have to lower than the transport layer
(tcp/udp etc), and even lower still, somewhere below the internet layer
(IPv4, IPv6 etc) and start from scratch tbh, define a new
internet-like-thing which isn't the internet and doesn't use any of the
internet stack, components or protocols.

Or am I missing the point too?

Best,

Nathan

Nathan wrote:
>
> Mike Kelly wrote:
> > On Mon, Oct 4, 2010 at 9:20 AM, Eric J. Bowman
> > <eric@...> wrote:
> >> Which is the same conclusion to be drawn from the thesis, absent
> >> that statement, with or without the mime-respect note.  The
> >> constraint in question is the embodiment of the decision to expand
> >> MIME from e-mail to become *the* tagging-and-bagging spec for IP
> >> network protocols. Chapter 6 extensively covers the topic of REST
> >> mismatches in HTTP, without mentioning the IANA registry...
> >
> > Why would that be a mismatch?
> >
> > You're missing the point; the argument has been that centralised
> > registration is _not a requirement_ for REST. Shared understanding
> > is the requirement, which can be achieved via other means than a
> > central registry.
>
> Shared understanding is the requirement...
>

This statement is accurate, but imprecise.  REST requires that the
shared understanding be network-based.  If the shared understanding
isn't network-based, it's library-based.  REST defines the difference
as the self-descriptive messaging constraint, defining uniform to mean
standardized and network-based.  Which is exactly what your post goes
on to explain...

>
> The only way to prevent this conflict at an architectural or transfer
> protocol level is to define a set of content type labels and a method
> for components to share which of the set they understand, for
> instance the Content-Type and Accept headers in the hypertext
> transfer protocol.
>

+1

>
> In order to understand content typed with a specific label, then a
> specification for that content type must be known, and given that
> some content type outwith the set could also share the same name, or
> that two content types within the set could share similar ambiguous
> names, then the only way to prevent conflict here is to store a
> reference to the content type specification along with the label for
> that content type, within the defined set.
>

Exactly like how domain name lookups work on IP by using the root name
servers to define a distributed registry.  You can use any domain name
you want on your LAN, but the shared understanding won't be network-
based, i.e. you can't extend your API over the Internet that way,
because it isn't an Internet domain name unless it's duly registered.

It isn't in-scope for HTTP to define any other mechanism for domain
name lookups, HTTP refers to URI which specifies DNS for IP networks.
It also isn't in-scope for HTTP to spec any other mechanism for
understanding Content-Type headers aside from the IANA registry.  Wrong
layer entirely.

Unregistered identifiers can't be forbidden, because that would prevent
new media types from evolving.  HTTP discourages persistent use of x
identifiers, in favor of re-using media types or registering new ones.
All HTTP is doing there, is defining a profile of the existing rules of
the underlying network:

http://tools.ietf.org/html/rfc1521#section-4

This is quite clear that unless you're using a string that's defined in
the IANA registry, you must use x- (which has been obsoleted by x.) so
as not to confuse anyone into thinking it's a standardized Internet
Media Type.

If HTTP doesn't override the network-based shared understanding of the
Content-Type header, how do you justify doing this at an even higher
level, i.e. in your HTTP API, and claiming it's network-based,
particularly when REST defines media type as RFC 2048, further
confirmed by Roy's clarification that self-descriptive = registered (at
the minimum)?

>
> Bringing it back to the real world, *the shared understanding of
> content type labels already exists* at an architectural level, we
> call the labels "Internet Media Types", they have a registry at IANA,
> and a well defined registration process, these aren't just transfer
> protocol specific, they are a shared understanding at the Internet
> Layer, which is two layers below any transfer protocol.
>
> This is why the transfer protocols you use on a daily basis, like
> SMTP, FTP and HTTP all use internet media types.
>

Just like how they all re-use URI and DNS.  Part of IP.

>
> In other words, to meet the shared understanding constraint and not
> use IANA registered media types you would not only have to go lower
> than (HTTP/DNS etc), but you'd have to lower than the transport layer
> (tcp/udp etc), and even lower still, somewhere below the internet
> layer (IPv4, IPv6 etc) and start from scratch tbh, define a new
> internet-like-thing which isn't the internet and doesn't use any of
> the internet stack, components or protocols.
>
> Or am I missing the point too?
>

I think your posts in this discussion since joining the group, have
exponentially increased my understanding of the point I've been trying
to make for a year now.  My conclusions were correct, but my rationale
was off.  Thinking of the IANA registry being as critical as DNS to the
operations of network protocols in general, further confirms REST's
rationale in considering it critical to any uniform interface style for
IP networking.

-Eric

I was hoping I could get some more clarity on some things.

What are some examples of serendipitous reuse that the Web offers
applications today?

One, I guess, is Caching. It has been suggested that admins won't
cache unfamiliar data types.

But what are some other examples? I heard a mention of link caching,
or some such thing. What is that referring to? Is that premised on a
proxy perhaps prefetching links in an HTML payload much like some
browsers do today? Something of that nature?

Are search engine search bots an example?

My other question refers to the use of bundling domain specific
information in a generic media type.

For example, a campaign donation. In theory, in the US, candidates
need to make their campaign donations accessible to the public.

It's not a leap to suggest a campaign website publishing a service
that returns an Atom list of donations based on some query.

For example, GET /donations?query=county:Los%20Angeles to see all
donations for Los Angeles county.

And the result can have links to the actual donation documents.

On the one hand, these donation documents could be
application/x-campaign-donation+xml, with a specification posted on
the campaign website. But that's an unregistered media type.

<donation>
     <name>Bob Eubanks</name>
     <date>09/01/2010</date>
     <amount>25.00</amount>
</donation>

On the other hand, it could be simply text/html:

<html>
<body>
<dl>
     <dt>Name</dt><dd>Bob Eubanks</dd>
     <dt>Date</dt><dd>09/01/2010</dd>
     <dt>Amount</dt><dd>$25.00</dd>
</dt>
</body>
</html>

Here's my issue.

The application/x-campaign-donation+xml is not self descriptive, since
it is unregistered. Therefore it has no expectation of getting any
reuse. It may well not even be cached, even with appropriate caching
headers.

The HTML version is self descriptive, but it's only self descriptive
of HTML. It's not self descriptive of a campaign donation. There is no
way to identify this resource as a campaign donation. It can benefit
from some reuse, notably caching, potentially google, etc. But there
can be no expectation of reuse at the domain level. For example, if
someone wanted to track the rate of donations by county, they can not
do that on the HTML payload, as they have no documentation of the
domain elements within the payload. This has no semantics outside of
HTML, because that's all it is identified with.

Much like the difference between application/xml and
application/x-campaign-donation+xml. Both are XML, but one has the
campaign donation semantics associated with it.

That's my conflict with all this. That using generic containers, you
may only be able to get domain knowledge through introspection, yet
introspection is considered a bad practice, that's one reason cited
why application/xml is not a proper media type to use.

I was hoping this conundrum could be discussed to learn how in
practice this conflict can be overcome.

Regards,

Will Hartung
(willh@...)

Will Hartung wrote:
>
> That's my conflict with all this. That using generic containers, you
> may only be able to get domain knowledge through introspection, yet
> introspection is considered a bad practice, that's one reason cited
> why application/xml is not a proper media type to use.
>

Introspection to determine sender intent is bad practice -- sender
intent should be declared by media type.  Semantics of the payload are
not.  The media type needs to tell me what kind of processor to use, in
order to understand the semantics of the payload.  These semantics
can't be understood unless the payload can first be decoded.  But they
have no bearing on the sender's intended processing model.

There are about a bazillion different uses for HTML, from campaign
donations, to banking, to airline reservations, to etc. etc. etc. and
so on and so forth, all of which share the same processing model.
Determining the semantics of the payload is a separate problem -- first
you need to know how to decode the payload, and that sender intent is
what a media type is self-descriptive of.

In many cases, the data type is XHTML 1.0, which may be sent as
text/html or as application/xhtml+xml.  If the rules are followed, the
semantics of the payload are exactly the same either way, because they
have nothing to do with the processing model being HTML vs. XML.  You
can use RDFa to annotate any standard element with domain-specific
vocabulary.  Or microformats, or microdata, or linked RDF, or whatever
else comes along -- using any of which has no bearing on media type.

-Eric

>
> In many cases, the data type is XHTML 1.0, which may be sent as
> text/html or as application/xhtml+xml.
>

Or as text/plain, in which case the payload has no semantics -- it's
intended to be read as a document, not processed as HTML or XML.

-Eric

Will Hartung wrote:
>
> What are some examples of serendipitous reuse that the Web offers
> applications today?
>

This has already been discussed at length.  The entire security
architecture of the Internet is based on media types.  Anything and
everything called a "Web accelerator" is based on media types.  DNS
accelerators, like the one Google makes, are based on media types.  The
point is that you can't know; all you can do to allow intermediaries to
participate in the communication as smart agents, rather than just as
routers, is to use the media types common to the deployed network
infrastructure.

>
> One, I guess, is Caching. It has been suggested that admins won't
> cache unfamiliar data types.
>

Or block them altogether as attempts at tunneling.

>
> But what are some other examples? I heard a mention of link caching,
> or some such thing. What is that referring to? Is that premised on a
> proxy perhaps prefetching links in an HTML payload much like some
> browsers do today? Something of that nature?
>

Yes.  How can anything be prefetched if the agent doesn't know what a
link is?  How can the security considerations of the payload be known
to anyone on the network unless it's been peer reviewed as part of the
public approval process for standards-tree media types?

>
> Are search engine search bots an example?
>

Yes, they know what <a href> means when the media type is text/html or
application/xhtml+xml.  They don't know what those URIs in your JSON
sent as application/json mean, other than they're strings of text.

>
> On the one hand, these donation documents could be
> application/x-campaign-donation+xml, with a specification posted on
> the campaign website. But that's an unregistered media type.
>

No, it's simply not a media type.  The definition of media type is
reserved for those things approved for inclusion in the IANA registry.
The proper prefix is 'x.' not 'x-'.  The '+xml' suffix is meaningless,
only media types approved as RFC 3023-compliant XML media types give
that suffix any meaning.  You're sending application/$.

>
> <donation>
>     <name>Bob Eubanks</name>
>     <date>09/01/2010</date>
>     <amount>25.00</amount>
> </donation>
>
> On the other hand, it could be simply text/html:
>
> <html>
> <body>
> <dl>
>     <dt>Name</dt><dd>Bob Eubanks</dd>
>     <dt>Date</dt><dd>09/01/2010</dd>
>     <dt>Amount</dt><dd>$25.00</dd>
> </dt>
> </body>
> </html>
>

You're comparing data types, not media types.  You need to understand
the vast difference between the two -- HTML tables (which is more
correct for your data structure) have a thead-tfoot-tbody structure
which allows for progressive rendering.  It's been extensively peer-
reviewed and improved in the public arena over many years, for both
forward and backward compatibility, extensibility, processing into a
DOM such that it may have bindings for scripting and styling.  The
security considerations are a matter of public record, there are
bindings such that the user agent's accessibility API may be scripted,
there's a forms language which relates how protocol methods are to be
used, the semantics of which URIs are to be embedded and which are to
be selected by the user and which are styles/scripts/namespace
identifiers is clearly defined, and so on and so forth.

This is the network-based shared understanding represented by both HTML
media types.  I can't deduce anything of the sort from application/$.
Why would you want to duplicate all that effort to recreate HTML for an
application that's right up HTML's alley to begin with?

>
> The application/x-campaign-donation+xml is not self descriptive, since
> it is unregistered. Therefore it has no expectation of getting any
> reuse. It may well not even be cached, even with appropriate caching
> headers.
>

It's an unknown quantity with no public information about its peer-
reviewed security considerations regarding its use on IP networks
across multiple protocols.  Why would I let it cross my boundary?  What
possible incentive do I have?  Whereas the IANA registry allows me to
make an *informed* decision as to whether or not to allow a media type
through a firewall.  Granted, that's a worst-case scenario, but then
again it's often the case with Java/Javascript/Flash, so why would you
expect anything unknown to fare any better?

>
> The HTML version is self descriptive, but it's only self descriptive
> of HTML. It's not self descriptive of a campaign donation.
>

By that logic, text/html is not self-descriptive of *anything* and
every use of HTML thus requires its own media type -- one for online
banking, another for airline reservations, yet another for event
ticketing, still another for registering a domain name, yet another to
purchase crap from Amazon, then another to purchase crap from BestBuy
because Amazon and BestBuy can't agree on semantics...

>
> There is no way to identify this resource as a campaign donation.
>

Of course there is.  A hypertext API is self-documenting.  An HTML
system which allows you to track these things is encapsulated around
whatever your backend system is.  Does the natural language of the text
tell you your list or table of things are campaign donations?  Are the
forms marked up such that you know you're entering someone's name
followed by a dollar value?  Then clearly, the representation is
describing a campaign donation resource, even without RDFa, which you
only need to make it machine-readable.  The resource means whatever its
representations say it means, not its media type, which only defines
the sender's intended processing model.

>
> can benefit from some reuse, notably caching, potentially google,
>

Why would Google bother indexing it, when it can't know what a link
even is?  Or an image?  Or how to construct a URI from a form?  Or
anything else anyone assumes Google magically just knows, when the
reality is that Google's behavior is (mostly) based on media types?

>
> etc. But there can be no expectation of reuse at the domain level.
> For example, if someone wanted to track the rate of donations by
> county, they can not do that on the HTML payload, as they have no
> documentation of the domain elements within the payload.
>

Huh?  Why can't you provide them a search interface which tells them
exactly what they're searching for, with natural-language text
explaining that interface, exactly like Google does?  Or better yet, if
you're re-using HTML, then why can't those folks just google for what
they're after from your domain specifically?  You're describing exactly
the sort of routine, everyday HTML application the Web thrives on.
REST doesn't require you to abandon all that and strike off on your own.

>
> Much like the difference between application/xml and
> application/x-campaign-donation+xml. Both are XML, but one has the
> campaign donation semantics associated with it.
>

No, one is XML, the other one is application/$ and any assumption that
it's XML requires introspection of the payload to confirm -- that's the
opposite of being self-descriptive.

-Eric

Will,

On Oct 6, 2010, at 3:52 AM, Will Hartung wrote:

> I was hoping I could get some more clarity on some things.
>
> What are some examples of serendipitous reuse that the Web offers
> applications today?

Serendipitous reuse happens any time an application is realized (when a user
agent engages in communication with servers on behalf of some user goal).

One might argue that services are built with some primary application in mind
and that this application is then not reuse, but I think that is secondary. What
is important is that REST enables clients to use what they are given by the
servers in previously unanticipated ways. Hence we call it *re*-use and not sort
of *again*-use.

>
> One, I guess, is Caching. It has been suggested that admins won't
> cache unfamiliar data types.

I do not see how that relates to reuse? Can you explain?


Jan

>
> But what are some other examples? I heard a mention of link caching,
> or some such thing. What is that referring to? Is that premised on a
> proxy perhaps prefetching links in an HTML payload much like some
> browsers do today? Something of that nature?
>
> Are search engine search bots an example?
>
> My other question refers to the use of bundling domain specific
> information in a generic media type.
>
> For example, a campaign donation. In theory, in the US, candidates
> need to make their campaign donations accessible to the public.
>
> It's not a leap to suggest a campaign website publishing a service
> that returns an Atom list of donations based on some query.
>
> For example, GET /donations?query=county:Los%20Angeles to see all
> donations for Los Angeles county.
>
> And the result can have links to the actual donation documents.
>
> On the one hand, these donation documents could be
> application/x-campaign-donation+xml, with a specification posted on
> the campaign website. But that's an unregistered media type.
>
> <donation>
>    <name>Bob Eubanks</name>
>    <date>09/01/2010</date>
>    <amount>25.00</amount>
> </donation>
>
> On the other hand, it could be simply text/html:
>
> <html>
> <body>
> <dl>
>    <dt>Name</dt><dd>Bob Eubanks</dd>
>    <dt>Date</dt><dd>09/01/2010</dd>
>    <dt>Amount</dt><dd>$25.00</dd>
> </dt>
> </body>
> </html>
>
> Here's my issue.
>
> The application/x-campaign-donation+xml is not self descriptive, since
> it is unregistered. Therefore it has no expectation of getting any
> reuse. It may well not even be cached, even with appropriate caching
> headers.
>
> The HTML version is self descriptive, but it's only self descriptive
> of HTML. It's not self descriptive of a campaign donation. There is no
> way to identify this resource as a campaign donation. It can benefit
> from some reuse, notably caching, potentially google, etc. But there
> can be no expectation of reuse at the domain level. For example, if
> someone wanted to track the rate of donations by county, they can not
> do that on the HTML payload, as they have no documentation of the
> domain elements within the payload. This has no semantics outside of
> HTML, because that's all it is identified with.
>
> Much like the difference between application/xml and
> application/x-campaign-donation+xml. Both are XML, but one has the
> campaign donation semantics associated with it.
>
> That's my conflict with all this. That using generic containers, you
> may only be able to get domain knowledge through introspection, yet
> introspection is considered a bad practice, that's one reason cited
> why application/xml is not a proper media type to use.
>
> I was hoping this conundrum could be discussed to learn how in
> practice this conflict can be overcome.
>
> Regards,
>
> Will Hartung
> (willh@...)
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hi folks,

one of the big benefits of REST is the caching ability. Is it possible to use a
reverse proxy cache AND https? This might be very useful in enterprise
scenarios, but i dont have any experience with squid & co...

Or are there any other recommendations to secure the resource exchange?

Regards,
Jakob

This is possible. I would suggest checking squid docs and the squid-users
mailing list.

Subbu

On Oct 6, 2010, at 1:33 AM, jakobstrauch wrote:

> Hi folks,
>
> one of the big benefits of REST is the caching ability. Is it possible to use
a reverse proxy cache AND https? This might be very useful in enterprise
scenarios, but i dont have any experience with squid & co...
>
> Or are there any other recommendations to secure the resource exchange?
>
> Regards,
> Jakob
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Weekend fun (oh, how I wish).

Here is an example of someone spreading recommendations who clearly doesn't have
a grasp on the subject matter.  I wish this were a joke, but alas, it's not.
http://www.readwriteweb.com/cloud/2010/10/another-10-mistakes-made-by-api-provid\
ers.php

Cheers,

- Steve

--------------
Steve G. Bjorg
http://mindtouch.com
http://twitter.com/bjorg