Subject: FYI: new draft of site-meta; now well-known

From: Mark Nottingham <[email-masked]>
Date: Sun, 12 Jul 2009 13:38:32 +1000

See:
   http://bit.ly/48bdmV

Cheers,

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

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 12 Jul 2009 18:33:49 -0700

Excellent!  Thanks for writing this up!
- Brad

On Sat, Jul 11, 2009 at 8:38 PM, Mark Nottingham <[email-masked]> wrote:

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 11:39:54 +1000

No worries.

One thing I'd like early and broad feedback on is that the selection  
of "/.well-known/" as the distinguished path prefix is appropriate; if  
someone has a reason that we shouldn't use this, please speak up now!

Cheers,

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 12 Jul 2009 18:45:01 -0700

FWIW, I'm happy with it, and I think I was one of the most grumpy ones about
the potential namespace conflicts of well-known URIs.  I spent a fair bit of
time writing parsers for sites and sites' URLs, so I'm acutely aware of
issues like this.  I think "/.well-known/" strikes the right balance between
obscurity (two semi-'weird' characters), and legibility, and "feels" like a
hidden directory, starting with a period.
On Sun, Jul 12, 2009 at 6:39 PM, Mark Nottingham <[email-masked]> wrote:

> No worries.
>
> One thing I'd like early and broad feedback on is that the selection of
> "/.well-known/" as the distinguished path prefix is appropriate; if someone
> has a reason that we shouldn't use this, please speak up now!
>
> Cheers,
>
>
>

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 12 Jul 2009 22:45:41 -0400

This looks good. I'm historically opposed to well-known URIs, but
have mellowed to pragmatism in the past several years.
I'm very happy to see the spec cover the minimum needed to
do the job and you successfully avoided 'discovery' and left the definition
of
sub-paths and query parameters to the spec for each well known location.

I have spotted two issues:

1) The problem with the current wording is that it leaves
the use of fragment identifiers ambiguous in specs
that defined well-known locations. I would suggest addressing it to
remove the ambiguity.

   It MAY also contain additional information, such as the syntax of
   additional path components, query strings, or fragment identifiers
   to be appended to the well-known URI, or protocol-specific details
   (e.g., HTTP [RFC2616] method handling).

2) You explain that the spec doesn't say anything about the formats and
media-types
to be expected at a well-known URI, but fail to mention that the same
lack of guarantee also applies to the URI "/.well-known/" itself. To the end
of Section 3 you could add:

   Note that this specification also does not define a format or media-type
   for the resource at "/.well-known/" and clients should not expect a
   resource to exist at that location.

   Thanks,
   -joe

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 17:03:14 +1000

Thanks.

Agreed on both points; I'll incorporate into the next drop.

On 13/07/2009, at 12:45 PM, Joe Gregorio wrote:

> do the job and you successfully avoided 'discovery' and left the  
> definition of
> 2) You explain that the spec doesn't say anything about the formats  
> and media-types

---

From: Peter Koch <[email-masked]>
Date: Mon, 13 Jul 2009 09:24:56 +0200

>   http://bit.ly/48bdmV

                        Defining Well-Known URIs
                     draft-nottingham-site-meta-02

The IANA registration policy could benefit from a disambiguation.  Section
5.1 says "Designated Expert" with "Specification Required", but then says
"typically published in an RFC or Open Standard".  The threshold for
"Specification Required" is lower, so it's unclear to me whether the
additional clause is intended to provide guidance only or is meant to
be normative.  Later, 5.1.1 seems to imply that change control with all
specifications backed by an RFC lies with the IETF, which isn't
necessarily the case.

On the choice of the name:

   It's short, descriptive and according to search indices, not widely
   used.

It's descriptive in a certain language environment but at the same time
it's a protocol element that is likely exposed to end users. There's an
odd chance that helpful implementations will provide localizations (like
some do today for email header fields).  A tag like "/.---.-" (W and K
in Morse code) looks less nice, but might reduce the temptaion of
translation.

-Peter

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Jul 2009 17:38:47 +1000

On 13/07/2009, at 5:24 PM, Peter Koch wrote:

> be normative.

The use of 'typically' makes it unambiguous.

> Later, 5.1.1 seems to imply that change control with all

Will fix this, thanks.

> in Morse code) looks less nice, but might reduce the temptaion of

It won't be exposed to end users; only site authors/administrators; do  
people routinely try to rename robots.txt?

Using a form with multiple dashes is much more likely to cause  
problems, IMO.

---

From: Sam Johnston <[email-masked]>
Date: Mon, 13 Jul 2009 11:06:44 +0200

On Mon, Jul 13, 2009 at 9:38 AM, Mark Nottingham <[email-masked]> wrote:

> Using a form with multiple dashes is much more likely to cause problems,
> IMO.
>

Agreed... I think /.well-known/ is highly sensible - kudos to whoever came
up with that (the former suggestions were, in contrast, very ordinary).

Sam