Subject: URIs, domains and authority

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Jan 2009 17:11:15 +1100

The site-meta draft <http://tools.ietf.org/id/draft-nottingham-site-meta-00.txt 
 > defines an "Über well-known location" for Web sites, in an attempt  
to allow discovery of metadata about a site without defining an  
application-specific URL (which is generally held to be bad practice).

In discussions about it, there's been some misunderstanding and  
disagreement about its scope of applicability. My original conception  
was that, for example,

   http://www.example.org/site-meta

would contain metadata specific and limited to the (HTTP, www.example.com 
, 80) triple; that is, it is scoped by the combination of protocol,  
host and port.

However, some potential users of this mechanism would like its scope  
to be broader. In particular, they'd like it to be cross-protocol;  
e.g., the metadata sourced from the URI above would also be  
potentially applicable to the following URIs:

   mailto:[email-masked]
   xmpp:[email-masked]

Note that here, both the protocol used, the port used, and even the  
hostname used (because www is dropped) are different. I.e., the  
metadata is not confined to the authority, but potentially applicable  
across an entire domain, for all protocols and ports.

AIUI, these use cases involve things like discovering security policy,  
configuration negotiation, etc. E.g., some want to discover XMPP- 
related policy by making a HTTP request to a pre-determined URI in the  
same domain.

My concern here is that there's a large difference between saying that  
a special file on a Web server defines metadata for that server (and  
only that server) and saying that it does so for -- potentially --  
everything to do with that domain. As such, I'd very much like to hear  
what the rest of the IETF community thinks of this issue (positive or  
negative).

There is some background discussion on the XRI TC mailing list <http://lists.oasis-open.org/archives/xri/ 
 >, which is one of the groups with this kind of use case.

I'll also mention that DNS is an obvious answer for this type of  
information, but AIUI the folks who are interested in this are wary of  
relying upon it, because of deployment concerns; i.e., some domain  
owners may not have the technical ability, knowledge or tools to  
modify their DNS to add records.

Regards,

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

_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jan 2009 00:28:48 -0700

Thanks Mark.

The specific context and use case in which this issue came up is described in my recent I-D: HTTP-based Resource Descriptor Discovery [1]. The idea is to define a method for obtaining resource descriptors (metadata) for URIs (such as POWDER, XRD, or Metalink). While the significant majority of use cases are HTTP-centric, there is at least one use case in which obtaining metadata for a mailto URI is needed. It is not likely that SMTP would be extended to offer XRD documents per email address...

The authority issue is explicitly raised in the discovery draft [2]:

   8.3.4. Descriptor Authority for Non-HTTP(S) URIs

   Site-Meta uses the HTTP protocol for providing metadata about the
   abstract 'web site' entity.  This raises the issue whether an HTTP
   server can speak authoritatively for a non-HTTP resource, namely, a
   resource identified by a URI with a scheme other than 'http' or
   'https'.

   From a deployment perspective, many organizations separate the
   administration responsibilities of their HTTP resources from other
   resources such as email (SMTP) or instant messaging (XMPP).  It would
   be an unexpected behavior in such organizations if the HTTP server
   provides authoritative information about identifiers belonging to
   other departments.

   The process defined in this memo was design with ease of deployment
   as one of its top priorities.  Since it is unlikely that protocols
   such as SMTP will introduce their own discovery extensions (which
   will realize any significant deployment in the foreseeable future),
   Site-Meta must be able to provide authoritative information regarding
   the descriptor location of non-HTTP(S) resources.

   The question whether Site-Meta can be considered authoritative for
   schemes other than 'http' and 'https' is application specific and is
   directly linked to their semantic and security considerations.  If
   the application requires an explicit grant of authority, other
   methods SHOULD be defined.

An outline for a simple DNS-based solution was proposed in the initial revision [3]:

   To obtain such authority, the owner of the domain (as represented by
   the administrator of its DNS records) MUST declare that Site-Meta is
   indeed allowed to provide such information.  To do so, the domain DNS
   records MUST include, for each domain or sub-domain for which the
   HTTP server has such authority, a TXT record with the exact value of
   '/site-meta non-http delegation enabled'.  [[The DNS record type and
   value are included in this draft only as a straw man proposal and are
   likely to change based on feedback received from the DNS community.
   Proposals for such record are requested.]]

   Resource-consumers MUST verify the existence of such DNS record
   before obtaining and utilizing the Site-Meta document for the
   discovery of non-HTTP(S) resources.  If no such record is found, the
   method fails.

but has been since removed. The idea was that if an application attempts to use Site-Meta for URI schemes other than 'http' or 'https', it should go to the DNS records for that authority and look for some indication that the domain owner has explicitly allowed it. The reason why this was dropped in the second revision was because I came to the conclusion that while the authority question is generic, the solution to it will most likely have to be application-specific.

The current use case for this is allowing OpenID [4] to accept email identifiers (mailto) alongside HTTP URIs to improve usability. However, since OpenID has other security requirements, it was not at all clear if the OpenID community will find the DNS solution sufficient. Solving the authority issue in a generic spec for a use cases that might not even be able to use it and without any implementation experience seems counterproductive. So instead, the current draft contains a discussion of the authority issue (included above) without offering any technical solutions.

---

However, the question Mark raised is very much still open and must be addressed by the discovery spec [1] in one of 4 ways:

1. The spec should explicitly limit discovery using Site-Meta to HTTP resources as defined by Mark (i.e. scoped by the combination of protocol, host and port).
2. The spec should ignore the authority question and focus on discovery for HTTP resources, leaving the applicability to non-HTTP resource up to other specs and applications to resolve.
3. The spec should raise the authority issue with regard to discovery using Site-Meta but leave it up to the application to resolve when used in such manner (current draft).
4. The spec should offer a technical solution (DNS-based or other) for using Site-Meta to discovery metadata about non-HTTP resources.

DNS has certainly been identified as the easiest place to "grant" such authority and as mentioned above, has been suggested as a solution. While technical accessibility is an important factor in this work (which is an unusual consideration at the IETF but critical in many communities this work emerged from such as OpenID and OAuth), it is not the primary concern but complexity for the common use cases. Since most use cases (if not all) are HTTP based, I do not want to complicate them in any way to accommodate some theoretical use cases for other protocols. So while DNS is a great approach, if used, I would rather it applied only to non-HTTP resources where there is such authority issue.

EHL

[1] http://tools.ietf.org/html/draft-hammer-discovery-01
[2] http://tools.ietf.org/html/draft-hammer-discovery-01#section-8.3.4
[3] http://tools.ietf.org/html/draft-hammer-discovery-00#section-8.3.3
[4] http://openid.net/specs/openid-authentication-2_0.txt

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Mark Nottingham
> Sent: Thursday, January 15, 2009 10:11 PM
> To: Apps Discuss
> Subject: URIs, domains and authority
>
> There is some background discussion on the XRI TC mailing list
> <http://lists.oasis-open.org/archives/xri/

---

From: Dave Cridland <[email-masked]>
Date: Fri, 16 Jan 2009 10:49:12 +0000

On Fri Jan 16 06:11:15 2009, Mark Nottingham wrote:
> AIUI, these use cases involve things like discovering security  
> policy,  configuration negotiation, etc. E.g., some want to  
> discover XMPP- related policy by making a HTTP request to a  
> pre-determined URI in the  same domain.

Who, and what policy? I've not seen any mention of this on the  
relevant XSF lists, nor here, so it'd be useful to get some  
background, this is far beyond my knowledge.

Otherwise I'm inclined to strongly question why discovery of XMPP  
policy cannot be done solely by XMPP - there's a number of obvious  
proposals that spring to mind, but really, involving the XMPP  
expertise at the XSF would be an obvious first step. I mean, the  
threads on this on the XRI list appear to be talking about entity  
capabilities, which is, franky, a well and truly solved problem in  
the XMPP world - look at XEP-0030 and XEP-0115.

I don't see how either xmpp or mailto scheme URIs can be generically  
processed to extract a URI anyway. (That is, by RFC 3986 rules, both  
xmpp:[email-masked] and mailto:[email-masked] have *no*  
authority, only a path of "[email-masked]").

Given that one understands the URI scheme, one can quite easily have  
different processing rules for both - indeed, technically, one has to  
to an extent.

I know that SMTP is likely to be different, but I'll have a better  
idea of potential solutions if I can understand the nature of the  
problem a bit better. (Specifically, SMTP admins do already put  
considerable operational data in the DNS, and adding a metadata URI  
might be fine).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 Jan 2009 10:26:07 -0500

> would contain metadata specific and limited to the (HTTP, www.example.com, 80)
> triple; that is, it is scoped by the combination of protocol, host and port.
>
> However, some potential users of this mechanism would like its scope to be
> broader. In particular, they'd like it to be cross-protocol; e.g., the metadata
> sourced from the URI above would also be potentially applicable to the
> following URIs:
>
>    mailto:[email-masked]
>    xmpp:[email-masked]
>
> Note that here, both the protocol used, the port used, and even the hostname
> used (because www is dropped) are different. I.e., the metadata is not confined
> to the authority, but potentially applicable across an entire domain, for all
> protocols and ports.

The issue goes beyond dropping the "www".  IBM, for example, does not send mail 
from "ibm.com".  We use our country-code subdomains, and some others.  So, where 
should one go to find metadata for the mailto protocol for us.ibm.com?  What 
about fr.ibm.com and jp.ibm.com, which each might have different rules?  And what 
about watson.ibm.com (which I use), which is under entirely different 
administration?

If this were to be done at all, I'd suggest extending the "site-meta" concept in 
a way such as "site-meta-xmpp" and "site-meta-mailto" (in other words, 
"site-meta-<protocol>").  And I'd make it be specific to the domain specified. 
So, to get the information in Mark's examples:

    http://www.example.org/site-meta
    http://example.org/site-meta-mailto
    http://example.org/site-meta-xmpp

Or perhaps we'd use parameters instead:

    http://www.example.org/site-meta            (for http on port 80)
    http://www.example.org/site-meta?port=8080
    http://example.org/site-meta?protocol=mailto

Note that "user@" isn't there for mailto or xmpp.  It's "site" meta, after all. 
If we want to include user-specific metadata, maybe do it with a parameter:

    http://example.org/site-meta-mailto?user=mnot
or
    http://example.org/site-meta?protocol=mailto&user=mnot

But I'm not sure it needs to go that far.

For my examples, we might have these:

    http://us.ibm.com/site-meta-mailto
    http://fr.ibm.com/site-meta-mailto
    http://jp.ibm.com/site-meta-mailto
    http://watson.ibm.com/site-meta-mailto

And note that I'd expect these two:

    http://www.ibm.com/site-meta
    http://ibm.com/site-meta

...to actually be different, though for most sites they would return the same 
metadata.

I agree with the concerns about doing this in DNS.  In many large organizations, 
DNS management is completely separate from management of the web servers, and 
having web-server metadata stored in DNS would add an unnecessary layer of 
organizational difficulty.

Barry

--
Barry Leiba, Senior Technical Staff  ([email-masked])
Internet Messaging Technology, IBM Research
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jan 2009 09:59:06 -0700

> [email-masked]] On Behalf Of Dave Cridland
> Sent: Friday, January 16, 2009 2:49 AM
> To: General discussion of application-layer protocols
> Subject: Re: URIs, domains and authority
>

There are not suggested use case for XMPP URIs. They were mentioned as an example of a URI that *might* be used but there are no existing use cases or requirements. There is one use case for email identifiers which implies mailto (using email as identity identifiers in sign-on and registration).

> authority, only a path of "[email-masked]").

True, but they can both produce an addressable authority by understanding their structure. I agree though that referencing RFC 3986 would not be enough to extract their authority. Hmm. For some reason I was under the impression that they email address was the authority part but the lack of // make this assumption wrong.

For the sake of discussion, let's change the example to FTP. Can Site-Meta point to FTP related metadata?

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jan 2009 10:06:44 -0700

This just adds complexity and doesn't solve the problem. Using the protocol name in the Site-Meta resource doesn't give HTTP any more authority to describe such protocols.

Also, this whole business of dropping the 'www' (or adding it) is really not part of this discussion. http://www.example.com/site-meta doesn't speak on behalf of example.com, us.example.com, etc. This doesn't mean a specific application can't come up with their own rules (though it should be properly done using DNS CNAMEs).

EHL

> [email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, January 16, 2009 7:26 AM
> To: Mark Nottingham; Apps Discuss
> to be
> hostname

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jan 2009 09:28:51 -0800

Two comments: scope and technology

At 5:11 PM +1100 1/16/09, Mark Nottingham wrote:
>Note that here, both the protocol used, the port used, and even the hostname used (because www is dropped) are different.

Doing so means that the administrator of sub.domain.morelabels gets to declare the metadata and policy for domain.morelabels. That seems like a policy disaster waiting to happen. To make the case as gently as possible: should a web server at http://ietf.org get to define metadata and policy for .org?

If you forward with this, the semantics must be completely clear that the metadata and policy are for the exact domain name and subordinate domain names only.

I do not have a problem with a web server (HTTP on 80) declaring metadata and policy for hosts running other protocols and/or on other ports of the same domain or of subordinate domains, but others might be more sensitive to this than I.

>I'll also mention that DNS is an obvious answer for this type of information,

Yes

> but AIUI the folks who are interested in this are wary of relying upon it, because of deployment concerns; i.e., some domain owners may not have the technical ability, knowledge or tools to modify their DNS to add records.

Tough. If the metadata and policy is about the domain in the domain name, it should be in the DNS. A tool to put something structured in the DNS are no harder to write than a tool to put it on a web page: most of the work will be in getting the structure correct, not in putting the file in the right place on the servers.

Having said that, you will find people arguing forever about whether the policy is really about the domain in the domain name or the servers that are running on addresses that are pointed to by records for that domain name. This level of IETF ontology never results in better protocols for users.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jan 2009 10:50:02 -0700

> [email-masked]] On Behalf Of Paul Hoffman
>
> > but AIUI the folks who are interested in this are wary of relying
> upon it, because of deployment concerns; i.e., some domain owners may
> not have the technical ability, knowledge or tools to modify their DNS
> to add records.
>
> Tough. If the metadata and policy is about the domain in the domain
> name, it should be in the DNS. A tool to put something structured in
> the DNS are no harder to write than a tool to put it on a web page:
> most of the work will be in getting the structure correct, not in
> putting the file in the right place on the servers.

This is simply not true. There are many platforms and environments where developers simply don't have access to such layers (but have the ability to perform simple HTTP GET requests) such as web gadgets (iGoogle, MyYahoo, OpenSocial, etc.).

EHL

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jan 2009 10:07:31 -0800

>This is simply not true. There are many platforms and environments where developers simply don't have access to such layers (but have the ability to perform simple HTTP GET requests) such as web gad…

Are you talking about publishing or getting published results? For publishing, if someone has the authority to tell the policy and metadata for a domain, they need to have access  to the location to do it. For asking, everyone has access to the DNS.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 16 Jan 2009 10:10:30 -0800

On Fri, Jan 16, 2009 at 10:07 AM, Paul Hoffman <[email-masked]> wrote:

> >This is simply not true. There are many platforms and environments where
> developers simply don't have access to such layers (but have the ability to
> perform simple HTTP GET requests) such as web gadgets (iGoogle, MyYahoo,
> OpenSocial, etc.).
>
> Are you talking about publishing or getting published results? For
> publishing, if someone has the authority to tell the policy and metadata for
> a domain, they need to have access  to the location to do it. For asking,
> everyone has access to the DNS.

For asking, a lot of people do not have access to DNS, because the API
abstracts it away. See the list of examples above. You could add to that any
number of web APIs that export only HTTP interface (not a full network
stack).

-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jan 2009 10:18:41 -0800

At 10:10 AM -0800 1/16/09, Breno de Medeiros wrote:
>For asking, a lot of people do not have access to DNS, because the API abstracts it away. See the list of examples above. You could add to that any number of web APIs that export only HTTP interface (not a full network stack).

I thought Mark was talking about applications having access to the data, not people, but I could have been mistaken. If it is applications, they do not need to go through an API that might abstract away things like a DNS RRtype.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 16 Jan 2009 10:22:14 -0800

On Fri, Jan 16, 2009 at 10:18 AM, Paul Hoffman <[email-masked]> wrote:

> I thought Mark was talking about applications having access to the data,
> not people, but I could have been mistaken. If it is applications, they do
> not need to go through an API that might abstract away things like a DNS
> RRtype.

Applications that are to be deployed in environments where _there_is_no_API_
to get to the DNS layer (see examples above, there are many, many others)
_have_to_do_without_DNS_

-- 
--Breno

+1 (650) 214-1007 desk

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 Jan 2009 13:30:49 -0500

> I thought Mark was talking about applications having access to the data, not
> people, but I could have been mistaken. If it is applications, they do not need
> to go through an API that might abstract away things like a DNS RRtype.

Paul, I think the issue here is where applications are limited in which APIs they 
use.  You and I, perhaps, can say, "Damn, I can't do what I want here; I'll go 
write this bit in C."  Not everyone has that option, and not every development 
platform exposes what it thinks to be lower-level network interfaces.

And, as I said in my other note, even on the publishing side there are real 
barriers to putting this stuff in DNS.  It's often far, far easier (and less 
error prone) for a group that does web stuff to update a file on a web server 
than it is for that group to get someone else to make a change to the DNS info.

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jan 2009 11:17:57 -0800

At 1:30 PM -0500 1/16/09, Barry Leiba wrote:
>Paul, I think the issue here is where applications are limited in which APIs they use.  You and I, perhaps, can say, "Damn, I can't do what I want here; I'll go write this bit in C."  Not everyone has that option, and not every development platform exposes what it thinks to be lower-level network interfaces.

<sigh> OK. If an IAB member says "it's OK to push everything through port 80", I'll accept that. :-)

>And, as I said in my other note, even on the publishing side there are real barriers to putting this stuff in DNS.  It's often far, far easier (and less error prone) for a group that does web stuff to update a file on a web server than it is for that group to get someone else to make a change to the DNS info.

Let me turn that around, however. If this is metadata and policy about a domain (not just about the web server), maybe the DNS group will have a hard time finding someone in the web server group to reliably put the data on a stable web page.

Mark's question that started this tread was about expanding the content of the current draft beyond being about the web server serving the data.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 Jan 2009 14:26:04 -0500

> <sigh> OK. If an IAB member says "it's OK to push everything through port 80",

He-he-he.
Well, I *am* up for renewal, and we never know what the NomCom will do.
Seriously: No, I don't think everything should go through HTTP.  But I do think 
it's reasonable to put possibly extensive policy and configuration information 
there...

...especially when it's related to web services.

That said, I get your other point: as the concept is expanded beyond web 
services, it's more questionable.  I still contend that in some environments -- 
at least in the company with which I'm most familiar -- putting information about 
policies for email, XMPP, FTP, and the like behind an HTTP server would be much 
easier, administratively, than putting it in DNS.

It might well be quite the opposite elsewhere.

But the other things I said in my first message apply: the subdomain scope MUST 
be clean, and the information for the different protocols MUST be kept separate. 
Else it will be a True Mess.

Barry

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Jan 2009 10:06:16 +1100

And I think this is perhaps the crux of this and many other  
arguments 
^H^H^H^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions  
that are happening in the Web world now.

A number of innovators (often with the "Web 2.0" label) have been  
hacking (in the "good" sense) on the Web and have got to the point  
where they need to mint some standards. Since they've been hacking,  
they've by necessity worked within the sometimes quite narrow limits  
of deployed Web software -- browsers, servers, hosting facilities,  
etc. I.e., they have and need "running code."

So, it's not too surprising that they want to standardise things that  
work within those limits.

Personally, I have a few reservations with doing so:

1) It effectively dumbs down the Web to preclude anything that can't  
be done with a free University account with FTP access. Yes, I have  
seen this argument made (not in this discussion yet). This is a sad,  
constricted and very worrisome vision of the future of the Web.

2) It rewards those vendors who choose not to implement full  
specifications, and to service providers who provide feature- 
restricted services. Again, not a good road to be on.

3) The solutions that this leads to are often very convoluted and  
specific to the state of the implementations when it was conceived,  
creating more complex standards that are harder to factor, implement,  
secure, use, and evolve. Evolving a product or service is relatively  
easy, compared to changing a standard.

4) It fails to recognise that, by pushing the limits in carefully  
managed ways, we can encourage broader, more standards-compliant  
implementations and deployments to be made. In particular, it seems  
very odd to me to hear this kind of argument, when looking at the list  
of names behind efforts like OAuth (not to pick on them particularly);  
by defining a specification that requires a particular feature and  
adopting it, THEY CHANGE THE MARKET and encourage implementation of  
that feature.

Again personally, I think the right thing to do here is to find  
compromises between "working right now" and "sensible in the long  
term". site-meta (as I conceived it) was one such compromise; yes, a  
well-known URI isn't a particularly good thing, but it works, is easy  
to use, and they're already out there; if done well, site-meta can be  
the last one of those. However, making it authoritative for more than  
the site it's on crosses the line, to me.

I'd suggest the line is that it makes sense to accommodate the  
realities of widespread implementation, but it don't make sense to try  
to assure that a particular standard can be used with every last,  
arbitrarily constructed hosting system in the world.

Then, of course, someone will say "but what about [huge deployed  
hosted service X]?" What I find interesting here is that the same  
people are often representing the company that owns [huge deployed  
hosted service X]...

Cheers,

On 17/01/2009, at 5:22 AM, Breno de Medeiros wrote:

> >For asking, a lot of people do not have access to DNS, because the  
> API abstracts it away. See the list of examples above. You could add  
> to that any number of web APIs that export only HTTP interface (not  
> a full network stack).
>
> I thought Mark was talking about applications having access to the  
> data, not people, but I could have been mistaken. If it is  
> applications, they do not need to go through an API that might  
> abstract away things like a DNS RRtype.
>
> Applications that are to be deployed in environments where  
> _there_is_no_API_ to get to the DNS layer (see examples above, there  
> are many, many others) _have_to_do_without_DNS_
>
>
>
> -- 
> --Breno
>
> +1 (650) 214-1007 desk

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 16 Jan 2009 15:28:56 -0800

On Fri, Jan 16, 2009 at 3:06 PM, Mark Nottingham <[email-masked]> wrote:

> arguments^H^H^H^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions
> A number of innovators (often with the "Web 2.0" label) have been hacking
> (in the "good" sense) on the Web and have got to the point where they need
> to mint some standards. Since they've been hacking, they've by necessity
> worked within the sometimes quite narrow limits of deployed Web software --
> browsers, servers, hosting facilities, etc. I.e., they have and need
> "running code."
>
> So, it's not too surprising that they want to standardise things that work
> within those limits.
>
> 1) It effectively dumbs down the Web to preclude anything that can't be
> done with a free University account with FTP access. Yes, I have seen this
> argument made (not in this discussion yet). This is a sad, constricted and
> very worrisome vision of the future of the Web.
>
> specifications, and to service providers who provide feature-restricted
> services. Again, not a good road to be on.
>
> 3) The solutions that this leads to are often very convoluted and specific
> to the state of the implementations when it was conceived, creating more
> complex standards that are harder to factor, implement, secure, use, and
> evolve. Evolving a product or service is relatively easy, compared to
> changing a standard.
>
> 4) It fails to recognise that, by pushing the limits in carefully managed
> ways, we can encourage broader, more standards-compliant implementations and
> deployments to be made. In particular, it seems very odd to me to hear this
> kind of argument, when looking at the list of names behind efforts like
> OAuth (not to pick on them particularly); by defining a specification that
> requires a particular feature and adopting it, THEY CHANGE THE MARKET and
> encourage implementation of that feature.
>
> Again personally, I think the right thing to do here is to find compromises
> between "working right now" and "sensible in the long term". site-meta (as I
> conceived it) was one such compromise; yes, a well-known URI isn't a
> particularly good thing, but it works, is easy to use, and they're already
> out there; if done well, site-meta can be the last one of those. However,
> making it authoritative for more than the site it's on crosses the line, to
> me.

Nobody here is suggesting that this standard make it authoritative, just
delegating the decision to applications. This is a sensible thing to do from
a modularity standpoint, and it is bad when standards try to push decisions
lower in the network layer than they have to be.

For illustrative purposes, consider the SSL and IPSEC standards. The IPSEC
standard provides much more comprehensive security properties, because it is
defined at the network layer. However, its deployment is limited to VPN and
other systems where there is a comprehensive managing authority for the
network. It does not provide sufficient granularity and flexibility for
deployment in open networks. On the other hand, SSL pushes security to the
transport/application layers and is much more flexible, addressing many use
cases which would be difficult or simply unwieldy to address using IPSEC.

SSL is not better or worse than IPSEC. It has a different set of operational
and deployment requirements in terms of security/flexibility.

It is my view (and from what I have heard, of several others in the XRI
committee) that the application environment where HRDD is going to be
applied is much more akin to the SSL setting than the IPSEC setting, and
that the flexibility to allow for applications that use this standard to
make end-to-end decisions on trust/authority issues is essential *due to the
nature of such applications* and not because of any current contingencies on
existing APIs. On the contrary, such web APIs are what they are because they
capture well the environment of the applications they need to support.

>
> I'd suggest the line is that it makes sense to accommodate the realities of
> widespread implementation, but it don't make sense to try to assure that a
> particular standard can be used with every last, arbitrarily constructed
> hosting system in the world.
>
> Then, of course, someone will say "but what about [huge deployed hosted
> service X]?" What I find interesting here is that the same people are often
> representing the company that owns [huge deployed hosted service X]...

Interesting that such hosting systems from fiercely competitive companies
have converged on the same solution. Maybe it is because they believe in
clean, useful APIs that capture the architecture of the application domain,
instead of trying to solve problems that are out of scope (and should remain
out of scope).

>> _there_is_no_API_ to get to the DNS layer (see examples above, there are
>> many, many others) _have_to_do_without_DNS_
>>
>>
>>
>> --
>> --Breno
>>
>> +1 (650) 214-1007 desk

-- 
--Breno

+1 (650) 214-1007 desk

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jan 2009 16:38:51 -0700

This is an interesting discussion but does not really help answering the
scope question of Site-Meta. The spec must answer the question of what is
the subject of the relationships described by the meta elements. It can also
be defined in contrast to Link header by asking, how is a link in Site-Meta
different from a Link header in the HTTP response to a GET request of the
root resource (GET / HTTP/1.1).

Site-Meta provides links between some "abstract web site" entity and
metadata documents. This discussion is finding out an acceptable definition
to this "abstract web site", and how it is different from what today the
HTTP root resource of a domain is used for (i.e. http://yahoo.com/).

The more detailed that definition is, the more restrictive the use of
Site-Meta becomes. The problem with the way this discussion has been framed
initially, is that it asks about authority across protocols. An HTTP
application that collects information about people and their email
addresses, should surely be allowed to use Site-Meta to publish their
findings, and provide a way to map between the email address to the HTTP
descriptor it produced?

I think the key here isn't defining the "abstract web site" directly, but
trying to define how it is different from the root resource and when each
should be used.

My use case is simple: I want Site-Meta to provide information about URIs,
regardless of their scheme, via HTTP. What you do with this information
should be out of scope.

EHL

> work within those limits.

This is less about the hacking part and more about trying to deploy a grand
vision in a world that is not yet ready or accommodating it. This debate
goes far beyond the technical details of standardizing limited environment.
There is a significant culture clash between communities like the IETF and
communities like OAuth. But this is completely off topic for the technical
question I would like to see resolved here.

> adopting it, THEY CHANGE THE MARKET and encourage implementation of

The "names" behind OAuth, if you look at actual leadership, contribution,
and influence are all individuals with practically zero influence on web
deployment and market structure. Yes, big companies join towards the end,
but the core of the work, and the 'soul' of the project very completely
anchored with the philosophy of maximizing accessibility and making sure it
is compatible with as many limited framework as possible.

And that was the most significant reason for its adoption. In fact, many
people argue that it didn't go far enough in simplicity and that is still
hurting adoption.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jan 2009 16:41:08 -0700

I included both a reply at the top and inline... Sorry for the confusion.

EHL

On 1/16/09 3:38 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Jan 2009 10:52:28 +1100

On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote:
> Nobody here is suggesting that this standard make it authoritative,  
> just delegating the decision to applications. This is a sensible  
> thing to do from a modularity standpoint, and it is bad when  
> standards try to push decisions lower in the network layer than they  
> have to be.

Possibly. I'd be OK with defining the scope of site-meta to be the  
site it's on by default, whilst leaving the door open for others to  
use it beyond that scope on a per-application basis (with appropriate  
warnings). Does that work for you, and does it work for others?

> Interesting that such hosting systems from fiercely competitive  
> companies have converged on the same solution. Maybe it is because  
> they believe in clean, useful APIs that capture the architecture of  
> the application domain, instead of trying to solve problems that are  
> out of scope (and should remain out of scope).

Touché :)

However, often they're less than "clean, useful APIs that capture the  
architecture of the application domain" and more like whatever can get  
out the door fastest. That's not a criticism of any one company, BTW,  
but more of a comment on the state of innovation in Silicon Valley.  
It's fast and furious and about capturing mind-share, but a lot of it  
is throwing things at the wall and seeing what sticks. It's not about  
building infrastructure that's going to stand the test of time and be  
a good internet citizen.

Cheers,

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 16 Jan 2009 15:57:11 -0800

On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham <[email-masked]> wrote:

> Possibly. I'd be OK with defining the scope of site-meta to be the site
> it's on by default, whilst leaving the door open for others to use it beyond
> that scope on a per-application basis (with appropriate warnings). Does that
> work for you, and does it work for others?
>

I understand that is what the spec currently does, i.e., delegates authority
question to the applications. Does it not?

-- 
--Breno

+1 (650) 214-1007 desk

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Jan 2009 11:05:19 +1100

The scope isn't well-defined in the current spec.

On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote:

> use it beyond that scope on a per-application basis (with  
> appropriate warnings). Does that work for you, and does it work for  
> others?
>
> I understand that is what the spec currently does, i.e., delegates  
> authority question to the applications. Does it not?
>
>
>
> Cheers,
>
>
> --

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 16 Jan 2009 16:06:54 -0800

Eran's earlier response clarifies what it is the intended scope for the
spec.

-- 
--Breno

+1 (650) 214-1007 desk

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 16 Jan 2009 16:08:17 -0800

I should have added the sense. Therefore if that intended scope gets
expressed in the spec with potentially more clear language, then are your
concerns addressed?

-- 
--Breno

+1 (650) 214-1007 desk

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Jan 2009 11:24:24 +1100

Clarification: when I say "the spec" I mean site-meta, not Eran's  
other spec.

As I said, I'm OK with it. The reason we're having the discussion here  
is as a sanity check to see what others think...

Cheers,

On 17/01/2009, at 11:08 AM, Breno de Medeiros wrote:

> expressed in the spec with potentially more clear language, then are  
> your concerns addressed?
>
> Eran's earlier response clarifies what it is the intended scope for  
> the spec.
>
>

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 Jan 2009 20:49:29 -0500

> Possibly. I'd be OK with defining the scope of site-meta to be the site it's on
> by default, whilst leaving the door open for others to use it beyond that scope
> on a per-application basis (with appropriate warnings). Does that work for you,
> and does it work for others?

I would object very strongly to the idea that site-specific metadata found at
  http://x.y.z/site-meta
might automatically be considered applicable (much less "authoritative") to any 
domain other than x.y.z.  I can point out all sorts of cases where that's a truly 
bad idea.  And I think it's a *terrible* idea to think that "www" is somehow 
special -- are you *sure* that every domain that doles out subdomains will forbid 
"www" as a separately managed subdomain?  I'm not.

DKIM had issues related to this, and they were a very contentious part of the 
protocol.  Ultimately, we managed to have things apply to subdomains in some 
cases because we limited the situations, and the protocol always has the 
subdomain checked first (so the parent domain's data only applies as a default).

I highly recommend not trying to go there, though I realize it limits the utility 
of things -- for instance, having metadata at blogspot.com apply to all blogs 
hosted there would be useful; perhaps this sort of thing can be handled in the 
definition of the specific metadata involved, rather than be a general rule for 
how site metadata works.

Barry

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 16 Jan 2009 19:20:36 -0700

This entire discussion is about the Site-Meta spec alone.

My previous statement still applies:

EHL

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Friday, January 16, 2009 4:24 PM
> To: Breno de Medeiros
> Cc: Paul Hoffman; Eran Hammer-Lahav; Apps Discuss
> Subject: Re: hacking and standards [was: URIs, domains and authority]
>

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Jan 2009 13:55:36 +1100

Hi Barry,

Your last statement

>> I highly recommend not trying to go there, though I realize it  
>> limits the utility of things -- for instance, having metadata at  
>> blogspot.com apply to all blogs hosted there would be useful;  
>> perhaps this sort of thing can be handled in the definition of the  
>> specific metadata involved, rather than be a general rule for how  
>> site metadata works.

is what I think is on the table;

>> site it's on
>> on a per-application basis (with appropriate warnings).

Where "site it's on" is (protocol, hostname, port).

Do you read that as roughly equivalent, or are you thinking of  
something different?

Cheers,

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 Jan 2009 23:05:35 -0500

> Do you read that as roughly equivalent, or are you thinking of something
> different?

Mm... OK; I think I read that differently before.  Yes, it sounds like you and I 
agree here.

Barry

---

From: Tim Bray <[email-masked]>
Date: Sat, 17 Jan 2009 14:00:44 -0800

On Thu, Jan 15, 2009 at 10:11 PM, Mark Nottingham <[email-masked]> wrote:

> The site-meta draft <
> http://tools.ietf.org/id/draft-nottingham-site-meta-00.txt> defines an
> "Über well-known location" for Web sites, in an attempt to allow discovery
> of metadata about a site without defining an application-specific URL (which
> is generally held to be bad practice).

I assume it's well-known that this has been a long-time discussion over at
the W3C TAG, called Sitedata-36:
http://www.w3.org/2001/tag/group/track/issues/36

The discussion has been going on since 2003.

I think the notion that a "site" maps to the root of a host's URI space is
demonstrably wrong, and that carving out pieces of namespace is harmful.  My
opinion, stated in Feb. 2003, hasn't changed.  It's short enough to copy in:
===============================================

I took an action item last TAG telecon to raise a strawman proposal.

TBL launched this with his proposal at

http://lists.w3.org/Archives/Public/www-tag/2003Feb/0093.html.  He

outlines the problem and proposes a new HTTP header (the note says "HTTP

tag" but that's a typo), but isn't quite explicit enough in

acknowledging that we're inventing a new architectural thing, the notion

of a "site".

Here's how I'd come at it.  Right now the web architecture doesn't have

any formal notion of a "site", and software that tries to pretend it

does by and large doesn't do a very good job (as the author of two

large-scale web spiders I have bitter first-hand knowledge).  Things

like /robots.txt that try to pretend that a host is a site have problems

because, well, a host isn't always a site.

So let's introduce a formal notion of a "Web Site", which is a

collection of Resources, each identified by URI.  A resource can be in

more than one site - not an obvious choice, but it seems it would be

hard to enforce a rule to the contrary.

Since a Web Site is an interesting and important thing, it ought to be a

resource and ought to have a URI.  There is no point trying to write any

rules about whether all the resources on a site ought to be on the same

host or whether the site's URI should look like those of the resources.

Then you introduce a new HTTP header as TBL suggested.  I'd call it

"Web-site" or just "Site".  Any server could, but need not, include this

header in a response to a GET or HEAD request.

You could easily include this in the <head> of HTML documents along the

lines of

  <meta http-equiv="Web-site" content="http://example.com/site" />

Perhaps <link> would be better, or perhaps the HTML people might want to

define new markup for the purpose.

Of course, this leads inevitably to the question of what is a useful

representation for a site.  The kinds of stuff that could go there could

include robots info, language info, favicon.ico equivalent, RSS info,

p3p info, etc etc etc.  Unlike the RDDL issues we've been discussing, I

see little requirement for human readability, so this feels like a

natural for a small (but extensible) RDF vocabulary, who cares if it's

ugly.  The RDF assertions would mostly have as their subject the URI "",

which works well in this case.  -Tim
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 18 Jan 2009 09:15:32 +1100

Yes. Unfortunately, the TAG never made much progress on this.

As the introduction of site-meta tries to make clear, site-meta is  
*not* a generic metadata solution; it's only intended for the subset  
it's necessary to discover metadata *before* (or even without)  
accessing a resource.

E.g., P3P needs this because people need to know the privacy policy of  
a site before they send a request (thereby revealing Personally  
Identifying Information). Other uses need to find metadata for very  
large numbers of resources at the same time, and cannot spider them  
all to do so to discover the site's "shape."

I would readily agree that the use of the term "site" here is not the  
best choice, but "authority-data" is frankly a bit painful.

There have been a fair number of other proposals in this space  
(including some by yours truly, e.g., <http://www.w3.org/TR/ 
urispace>), but none have caught on. I suspect this is because many of  
them were too complex, and many of the requirements are quite diverse.  
Thus the extreme simplicity and generality of site-meta (the next  
version should be even more so).

Cheers,

On 18/01/2009, at 9:00 AM, Tim Bray wrote:

> I assume it's well-known that this has been a long-time discussion  
> over at the W3C TAG, called Sitedata-36: http://www.w3.org/2001/tag/group/track/issues/36
>
> I think the notion that a "site" maps to the root of a host's URI  
> space is demonstrably wrong, and that carving out pieces of  
> namespace is harmful.  My opinion, stated in Feb. 2003, hasn't  
> changed.  It's short enough to copy in:

---

From: Tim Bray <[email-masked]>
Date: Sat, 17 Jan 2009 14:31:51 -0800

>
> I would readily agree that the use of the term "site" here is not the best
> choice, but "authority-data" is frankly a bit painful.

Your proposal is for the use of a location hardwired to a particular host.
 Thus, by definition it is host metadata. If you changed the name it would
be more accurate and might avoid collisions with others working in the same
space.

I would be strongly opposed to progressing this document as long as it
claims to be about Web sites, because it's not.

I think that the host-metadata mechanism, as presented, might turn out to be
very useful, assuming it's relabeled.
 -Tim
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 18 Jan 2009 09:55:45 +1100

Well, it's host-port-protocol; i.e., a host (in the internet sense)  
can have more than one, potentially many more.

'authority' (in the URI sense, which is probably the right sense,  
given that this is rooted in URIs) doesn't even really cover it,  
because it doesn't include scheme.

Naming things is hard...

On 18/01/2009, at 9:31 AM, Tim Bray wrote:

> I would readily agree that the use of the term "site" here is not  
> the best choice, but "authority-data" is frankly a bit painful.
>
> Your proposal is for the use of a location hardwired to a particular  
> host.  Thus, by definition it is host metadata. If you changed the  
> name it would be more accurate and might avoid collisions with  
> others working in the same space.
>
> I would be strongly opposed to progressing this document as long as  
> it claims to be about Web sites, because it's not.
>
> I think that the host-metadata mechanism, as presented, might turn  
> out to be very useful, assuming it's relabeled.
>  -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 18 Jan 2009 10:27:36 +1100

..although host,port does uniquely identify, at least; so "authority"  
is probably the best fit.

That would make it
   /authority-data

with the upside of being more precise (and several people have noted  
the 'but a site is different' issue), with two (minor) downsides; a  
few more characters, and a more esoteric term.

I'm neutral on this; if I read Tim correctly, he's nearly or at lying  
down in the road against the current name (is this better?). Others?

On 18/01/2009, at 9:55 AM, Mark Nottingham wrote:

>> Your proposal is for the use of a location hardwired to a  
>> particular host.  Thus, by definition it is host metadata. If you  
>> changed the name it would be more accurate and might avoid  
>> collisions with others working in the same space.
>>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Jan 2009 15:30:19 -0800

At 10:27 AM +1100 1/18/09, Mark Nottingham wrote:
>..although host,port does uniquely identify, at least; so "authority" is probably the best fit.
>
>That would make it
>  /authority-data
>
>with the upside of being more precise (and several people have noted the 'but a site is different' issue), with two (minor) downsides; a few more characters, and a more esoteric term.
>
>I'm neutral on this; if I read Tim correctly, he's nearly or at lying down in the road against the current name (is this better?). Others?

I lay with Tim. "site" is way too loaded of a word. I also like "-data" instead of "-meta" because you can put things in there that someone would not call metadata.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 17 Jan 2009 18:14:00 -0700

I would like to hear from Tim how he would adjust the proposal to accommodate the term 'site'. I understand the objection but before giving up on calling this site-meta, would like to know if there are ideas on how to accomplish that.

EHL

> Sent: Saturday, January 17, 2009 3:28 PM
> To: Tim Bray
> Cc: Apps Discuss

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 17 Jan 2009 18:25:26 -0700

This really isn't meta or data. For the current use cases, it is all links. For future use cases, and semantically, it is really the HTTP header of the "web site". The reason we need this file is because we have no better place (DNS aside) to declare typed-relationships between the site/authority/domain/whatever and other resources. Today, people usually put those on the root resource which is wrong.

/authority-header is more accurate but might sounds a bit weird.

EHL

> Sent: Saturday, January 17, 2009 3:30 PM
> To: Apps Discuss
> the 'but a site is different' issue), with two (minor) downsides; a few
> more characters, and a more esoteric term.
> >
> I lay with Tim. "site" is way too loaded of a word. I also like "-data"
> instead of "-meta" because you can put things in there that someone
> would not call metadata.

---

From: Tim Bray <[email-masked]>
Date: Sat, 17 Jan 2009 17:44:51 -0800

On Sat, Jan 17, 2009 at 5:14 PM, Eran Hammer-Lahav <[email-masked]>
 wrote:

> I would like to hear from Tim how he would adjust the proposal to
> accommodate the term 'site'. I understand the objection but before giving up
> on calling this site-meta, would like to know if there are ideas on how to
> accomplish that.

Well, as I noted, the TAG's been wrestling with this for years, and I lost
touch with that debate in 2004.  I'm not sure why it's hard, from the Web's
point-of-view it'd be easy enough to assert that a Site is something that
other web resources can claim to be part of with a labeled link as in

<link rel="site"> in HTML, and perhaps some teeny XML namespace for more
generic use, which doesn't conflate hosts with sites, nor does it steal any
of the URI namespace.  It leaves only the problem of what to put there.
I'd originally suggested RDF, but Mark's draft vocabulary looks perfectly
sensible to me as far as it goes.

But I'll shut up at this point because I haven't been following closely and
haven't been thinking about the use cases around host+port metadata, which
is the current proposal.

It's just that claiming that this thing is about sites would be actively
harmful, so fix that and I'll shut up.

-T

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 17 Jan 2009 19:07:49 -0700

I'm trying to understand your thinking on this. So in your view a 'site' is something web resources associate themselves with (via links), and which can then be described. Because you use an association, you can assign a URI to this 'site' which can carry its own links and metadata.

The problem, of course, is that you have to check with each resource which site they are associated with.

I disagree that this can be the only valid definition of a site (self selected association with some site-URI), but am open to using a different name than site for Site-Meta if changing the name accomplishes consensus (or at least removes objections).

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Saturday, January 17, 2009 5:45 PM
To: Eran Hammer-Lahav
Cc: Mark Nottingham; Apps Discuss
Subject: Re: URIs, domains and authority

On Sat, Jan 17, 2009 at 5:14 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I would like to hear from Tim how he would adjust the proposal to accommodate the term 'site'. I understand the objection but before giving up on calling this site-meta, would like to know if there are ideas on how to accomplish that.

Well, as I noted, the TAG's been wrestling with this for years, and I lost touch with that debate in 2004.  I'm not sure why it's hard, from the Web's point-of-view it'd be easy enough to assert that a Site is something that other web resources can claim to be part of with a labeled link as in

<link rel="site"> in HTML, and perhaps some teeny XML namespace for more generic use, which doesn't conflate hosts with sites, nor does it steal any of the URI namespace.  It leaves only the problem of what to put there.   I'd originally suggested RDF, but Mark's draft vocabulary looks perfectly sensible to me as far as it goes.

But I'll shut up at this point because I haven't been following closely and haven't been thinking about the use cases around host+port metadata, which is the current proposal.

It's just that claiming that this thing is about sites would be actively harmful, so fix that and I'll shut up.

-T

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 17 Jan 2009 20:24:48 -0600

On Sat, Jan 17, 2009 at 07:07:49PM -0700, Eran Hammer-Lahav wrote:
> I'm trying to understand your thinking on this. So in your view a
> 'site' is something web resources associate themselves with (via
> links), and which can then be described. Because you use an
> association, you can assign a URI to this 'site' which can carry its
> own links and metadata.
> 
> I disagree that this can be the only valid definition of a site (self
> selected association with some site-URI), but am open to using a
> different name than site for Site-Meta if changing the name
> accomplishes consensus (or at least removes objections).

Well, listing all the things that make up a site can be, er, difficult.
So what alternative is there but to let things tell you what site(s)
they are in?

Also, just because some resource exists in some location where
many/most/all other resources are associated with a "site" does not mean
that one resource is too.

Perhaps this could be useful for dealing with XSS...

Nico

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 17 Jan 2009 21:04:22 -0700

Yes, everyone has their own definition of what a 'site' means...

EHL

> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Saturday, January 17, 2009 6:25 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; Apps Discuss

---

From: Tim Bray <[email-masked]>
Date: Sat, 17 Jan 2009 22:43:31 -0800

On Sat, Jan 17, 2009 at 6:07 PM, Eran Hammer-Lahav <[email-masked]>wrote:

>  I'm trying to understand your thinking on this. So in your view a 'site'
> is something web resources associate themselves with (via links), and which
> can then be described. Because you use an association, you can assign a URI
> to this 'site' which can carry its own links and metadata.
>
People who use, the web, and people who build the web, believe that there's
something called a "site" and that the notion is important; it's typically
what people get paid for building and is a common topic of conversation
among users.

The underlying software and protocols include no such notion.  Some people
see this as an irritant or shortcoming.   There is not a 1-1 mapping between
hosts and sites; big sites sprawl across dozens of hosts, and many small
sites share hosts.  Thus things like /robots.txt are irritating both in
theory and in practice.

The Web tends to think that anything that matters should be a "resource",
i.e. have a URI.  Thus, the proposal is to formalize the notion of a "site"
by agreeing

- that it is a resource and has a URI
- on ways to find that URI, e.g. in HTTP headers or HTML <link> elements or
whatever
- what you should expect to find when you dereference the site's URI.

That's all.  -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 18 Jan 2009 19:46:13 +1100

It's very hard. If evil.net asserts that it's part of the site  
citibank.com and is unquestioningly believed, all sorts of nasty  
things can happen.

Furthermore, spidering every possible resource to determine the shape  
of a site is unworkable for most use cases, so some sort of site map  
is required. If there isn't any grounding for that map (e.g., being  
limited to an authority), then two maps can assert that a single  
resource is part of both sites; now you have to deal with conflict  
resolution.

robots.txt, p3p.xml, favicon.ico, and the like are unfortunate hacks,  
yes, but they work, because they're grounded in a crisply defined  
scope -- a single and whole authority.

I think the use of the term 'authority' in the URI spec is very  
appropriate. "Site" is a term that people use when referring to  
portions of the Web; this mechanism is for machines, and doesn't  
*necessarily* have to align with the concept of "site."

BTW -- there was a substantial amount of feedback that XML was too  
complex and error-prone for this purpose, so the next draft is likely  
to be a header-like text format.

Cheers,

On 18/01/2009, at 12:44 PM, Tim Bray wrote:

> On Sat, Jan 17, 2009 at 5:14 PM, Eran Hammer-Lahav <[email-masked] 
> > wrote:
> accommodate the term 'site'. I understand the objection but before  
> giving up on calling this site-meta, would like to know if there are  
> ideas on how to accomplish that.
>
> Well, as I noted, the TAG's been wrestling with this for years, and  
> I lost touch with that debate in 2004.  I'm not sure why it's hard,  
> from the Web's point-of-view it'd be easy enough to assert that a  
> Site is something that other web resources can claim to be part of  
> with a labeled link as in
>
> <link rel="site"> in HTML, and perhaps some teeny XML namespace for  
> more generic use, which doesn't conflate hosts with sites, nor does  
> it steal any of the URI namespace.  It leaves only the problem of  
> what to put there.   I'd originally suggested RDF, but Mark's draft  
> vocabulary looks perfectly sensible to me as far as it goes.
>
> But I'll shut up at this point because I haven't been following  
> closely and haven't been thinking about the use cases around host 
> +port metadata, which is the current proposal.
>
> It's just that claiming that this thing is about sites would be  
> actively harmful, so fix that and I'll shut up.
>
> -T
>

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 18 Jan 2009 13:21:35 -0600

> Yes, everyone has their own definition of what a 'site' means...

Except I didn't touch on that topic.  I merely pointed out that listing
all the resources that make up a "site," whatever your definition of
that might be, is not realistic.

Yes, I did then mention XSS attacks, which does assume a notion of
"site," and a fairly weak one at that (is user-submitted content part of
a larger "site" built by others?).  That's the crux of XSS, isn't it?
Identifying the "source" ("authority") of content that is at what users
think of as "sites" may well help address XSS.

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 18 Jan 2009 13:33:27 -0600

> what people get paid for building and is a common topic of conversation

Any notion of "site" other than what users and developers already expect
is likely to fail to gain currency.

> sites share hosts.  Thus things like /robots.txt are irritating both in

For small sites sharing hosts virtualization comes to the rescue (or
could/should).  Yes, yes, if only HTTP/1.0 were no longer in use...

But anyways, the underlying hosts that make up a site aren't remotely a
part of the notion of "site" that _users_ have.  From a user's point of
view all that matters is the host/domain name part of the URL -- that
makes up a site.  And from an XSS point of view what matters is the
source of any one resource.  Users, of course, may not be aware of the
fact that many individual resources make up a "site" or that some such
resources are not really part of the same "site."

> - what you should expect to find when you dereference the site's URI.

Thus the crucial feature of a formalized notion of site is the second
one on your list, because it could actually be helpful.  The third item
might not be needed at all, since one could argue that without a way to
dereference a "site URI" one could simply conclude that it refers to the
owners of the DNS domain name of the site, for example (though I'm not
saying that the thirdd item is useless, in fact, I think it'd be
useful).

I would also add that it may be possible for a resource to be in
multiple sites, or that the site the resource appears to be in may
depend on the URI used to find the resource.  A single link to a
containing "site" may be insufficient.

> That's all.  -Tim

Agreed.

Nico

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Jan 2009 13:00:41 -0700

All of which seems to imply that the term 'site' is, well, useless.

That leaves us with other well defined terms:

- host
- domain
- authority

And with the following descriptions of the document:

- meta
- data
- header
- links

Any preferences?

EHL

> Sent: Sunday, January 18, 2009 11:33 AM
> To: Tim Bray
> Cc: Eran Hammer-Lahav; Apps Discuss

---

From: Tim Bray <[email-masked]>
Date: Sun, 18 Jan 2009 13:07:40 -0800

> choice, but "authority-data" is frankly a bit painful.

I agree with both halves of that sentence.  Why not just say "host
metadata"?  Anyone remotely net-literate knows that foo.com and
foo.com:8080are effectively different hosts. So simply assert that
"host metadata" is
short for "host-port-combination metadata".

 -Tim

---

From: John Leslie <[email-masked]>
Date: Sun, 18 Jan 2009 17:06:03 -0500

> All of which seems to imply that the term 'site' is, well, useless.

   Alas, yes: we can't map to "site" from anything we have.

> And with the following descriptions of the document:

   I strongly recommend "domain" if you're going to retrieve it with

htpp://example.com/site-meta

(well, of course, I don't recommend "site-meta", but you get the picture.

   And I have no problem with "meta"... though YMMV.

   Many folks may think of the name following "http://" as a "site",
but it's really a domain -- and the better the term fits the facts,
the happier we'll be in the long term.

   I also recommend (strongly) that the metadata exactly match the
domain -- no parent domains and no subdomains -- at least in the initial
version. It's far better for the webserver to serve multiple copies of
the same metadata for different domains, if that is really how the "site"
is organized.

--
John Leslie <[email-masked]>
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Jan 2009 09:21:04 +1100

No, a domain is 'example.com', not 'www.example.com',  
'us.example.com', 'foo.bar.example.com' or the myriad of other  
possibilities.

Likewise, a 'host' is 'foo.example.com', not 'foo.example.com:8000'.

If we rule out 'site' as a confusing colloquial name, it doesn't make  
sense to move to misusing an already defined term.

---

From: John Leslie <[email-masked]>
Date: Sun, 18 Jan 2009 17:44:51 -0500

> 'us.example.com', 'foo.bar.example.com' or the myriad of other  

   Please explain.

   (RFC 1034 leads me to believe all of those are "domains".)

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Jan 2009 16:26:45 -0700

HTTP Host header seems to accomplish what you want. It includes both the domain and port.

EHL

> Sent: Sunday, January 18, 2009 2:21 PM
> To: John Leslie

---

From: Tim Bray <[email-masked]>
Date: Sun, 18 Jan 2009 16:24:38 -0800

On Sun, Jan 18, 2009 at 2:21 PM, Mark Nottingham <[email-masked]> wrote:

> If we rule out 'site' as a confusing colloquial name, it doesn't make sense
> to move to misusing an already defined term.

You're right, but "authority-metadata" has three extra syllables, and while
I yield to nobody in the height of my pedantry, it feels awkward.  Anyhow,
I'm merely suggesting we use "host-meadata" as a an *abbreviation* for
host-port-pair-metadata.  -T
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Jan 2009 11:33:52 +1100

My examples were chosen poorly. Although "www.example.com" is a  
domain, the use of "example.com" includes that host, as per
> A domain is identified by a domain name, and consists of that part  
> of the domain name space that is at or below the domain name which  
> specifies the domain. A domain is a subdomain of another domain if  
> it is contained within that domain. This relationship can be tested  
> by seeing if the subdomain's name ends with the containing domain's  
> name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".

in that RFC, which is not desirable here.

Moreover, in common use there's almost as much confusion about  
"domain" as there is about "site"; people use domain to indicate  
something obtained from a registrar, not a hostname or subdomain.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Jan 2009 11:39:52 +1100

On 19/01/2009, at 11:24 AM, Tim Bray wrote:

> If we rule out 'site' as a confusing colloquial name, it doesn't  
> make sense to move to misusing an already defined term.
>
> You're right, but "authority-metadata" has three extra syllables,  
> and while I yield to nobody in the height of my pedantry, it feels  
> awkward.

Yeah, that's exactly how I got to "site" -- but I'd have avoided it if  
I knew it would cause this much kerfuffle.

>  Anyhow, I'm merely suggesting we use "host-meadata" as a an  
> *abbreviation* for host-port-pair-metadata.  -T

Not "host-meta"? I'm not against "host-metadata", but since we're  
chopping syllables...

Or, going in a completely different direction:
   http://www.example.com/my-meta

Cheers,

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 23 Jan 2009 15:45:07 +0100

> Any notion of "site" other than what users and developers already
> expect is likely to fail to gain currency.

Yes, but:
 
> From a user's point of view all that matters is the host/domain name
> part of the URL -- that makes up a site.

I disagree. Part of the problem with the user's point of view is that
it is not rigourously defined. But I've often hear users use "site"
for "group of Web resources managed together" and so
http://www.myuniversity.edu/maths and
http://www.myuniversity.edu/history are two different sites...
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Tim Bray <[email-masked]>
Date: Fri, 23 Jan 2009 09:26:21 -0800

---

From: Breno de Medeiros <[email-masked]>
Date: Fri, 23 Jan 2009 09:39:24 -0800

'site', 'domain', 'host', even 'authority' ... have multiple
definitions/understandings and could lead to confusion. So the burden
is on the spec to define what scope '/site-meta' has. The benefit of
using one or another of more or less ambiguous terms is a discussion
with diminishing returns. 'site-meta' can have a non-ambiguous meaning
even if 'site' does not.

On Fri, Jan 23, 2009 at 9:26 AM, Tim Bray <[email-masked]> wrote:
>> Not "host-meta"? I'm not against "host-metadata", but since we're chopping
>> syllables...
>
> host-meta works for me.  -T

-- 
--Breno

+1 (650) 214-1007 desk

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Jan 2009 11:37:33 -0600

> On Sun, Jan 18, 2009 at 01:33:27PM -0600,
>  Nicolas Williams <[email-masked]> wrote 
>  a message of 58 lines which said:
> 

True, the notion of site that users have is a bit slippery, and you
might not even get all users to agree as to what whether a particular
set of URIs makes up one site on N.  All the more reason, I guess, to
avoid the word 'site' altogether.
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Jan 2009 11:44:01 -0600

> From what I heard in this thread, all commonly used terms such as

'site-meta' is probably less ambiguous too than 'host-meta' (is the
latter information about the host, such as what OS it's running?  Or is
is information about the resources hosted on it?  And what about
related resources hosted on a different host but, from a user's p.o.v.,
still part of the same 'site'?).

So I agree.

---

From: Tim Bray <[email-masked]>
Date: Fri, 23 Jan 2009 10:08:01 -0800