Re: [apps-discuss] Looking at Webfinger

Way "late to the party" but I can speak from experience that deployment 
can be a real issue in some environments. It's all really straight 
forward in a small company or an environment where the identity team 
"owns" the root domain (e.g. example.com). However, if an entire other 
group in a large organization "owns" the root domain (home page for the 
site) and the identity team then needs to get them to make changes, the 
deployment solution gets brittle pretty quick. I've had our webfinger 
support broken at least twice because the "other" team didn't know that 
certain configs were required:)

Also, installing the "dynamic pluming" can be more problematic is these 
cases. It is possible to get apache rewrite rules or netscaler magic in 
place to make it work, it's just a more brittle deployment architecture.

Thanks,
George

On 7/4/12 6:58 PM, John Panzer wrote:
> Mark -- Of course I was speaking about practical realities of typical 
> web server administration and deployment.  In practical terms, adding 
> a new mod_rewrite rule or moral equivalent is going to be easier than 
> adding a new PHP script that connects to a database.  The latter is 
> just always going to be a much higher bar.
>
> And, something that returns per-user data is generally going to need a 
> dynamic service of some kind, unless your site has just a handful of 
> users and you don't mind going through a publishing exercise each time 
> you add or change a user...
>
> None of this has anything to do with the interface, just deployment 
> realities.  And in reality all of this is going to need a dynamic 
> service somewhere for each non-trivial site, this is all just a 
> question of how to hook it up.
>
> --
> John Panzer / Google
> jpanzer@google.com <mailto:jpanzer@google.com> / abstractioneer.org 
> <http://www.abstractioneer.org/> / @jpanzer
>
>
>
> On Wed, Jul 4, 2012 at 3:36 PM, Mark Nottingham <mnot@mnot.net 
> <mailto:mnot@mnot.net>> wrote:
>
>     On 05/07/2012, at 8:16 AM, John Panzer wrote:
>
>     > Just as a historical note.  The envisioned usage of host-meta
>     was originally to avoid a specification which mandated a
>     particular dynamic URL API at a particular /.well-known endpoint
>     (because it may not be feasible to do that across all
>     organizations and deployments).  The host-meta document itself
>     would be highly cacheable and so wouldn't incur an additional
>     network trip in the common case.
>     >
>     > Having a 3xx redirect is a reasonable alternative that allows a
>     similar escape hatch via something like mod_rewrite, albeit at the
>     cost of needing an additional network trip each time.  Since a
>     deployment can always avoid the 3xx redirect with additional
>     dynamic plumbing behind the well-known endpoint, I don't think
>     that's a horrible thing.
>     >
>     > An application-level redirect would be almost equivalent to an
>     HTTP redirect, but then there are two ways to do the same thing.
>      If _only_ an application-level redirect is allowed, then you have
>     to have at least a minimal dynamic service at the well-known
>     endpoint (no more mod_rewrite).  But the whole reason for this is
>     to avoid the requirement for a dynamic service behind well-known...
>
>     "dynamic" and "static" are properties of the implementation, not
>     the interface. HTTP doesn't require that any particular URL be
>     "dynamic"; anything can, with the right metadata, be cached (and
>     indeed, I've cached many, many things with the wrong metadata,
>     because of silly site operators and their ideas about "dynamic").
>
>     Now, if people want to target a particular implementation that
>     makes it easier to serve a particular style of URL without writing
>     code, fine, but let's not confuse things.
>
>     E.g., a URL like
>
>     http://example.com/.well-known/user/bob
>
>     is easy to serve in pretty much any way you like with Apache.
>
>     I'm also going to push back on the "it may not be feasible to do
>     that across all organizations and deployments" motivation. This is
>     a race to the bottom. The trick is to make it accessible enough to
>     get sufficient traction to pull everyone along, without pandering
>     to *everyone*'s requirements.
>
>     Regards,
>
>     --
>     Mark Nottingham http://www.mnot.net/
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss