Subject: Re: [wellknown-uri-review] A .well-known registration for review: ni

From: Eran Hammer <[email-masked]>
Date: Tue, 1 May 2012 14:44:54 +0000

I am writing this in my capacity as the registry's Designated Expert.

This will be an informal review as I have not received a proper review request using the template and email format specified in RFC 5785.

I have read through the document and have some concerns about its use of the Well-Known URI registry. When the registry was created, it was explicitly designed not to form a large namespace or allow the creation of resource trees within in. Section 1.1 is pretty explicit about this:

---
1.1.  Appropriate Use of Well-Known URIs

   There are a number of possible ways that applications could use Well-
   known URIs.  However, in keeping with the Architecture of the World-
   Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
   for general information retrieval or establishment of large URI
   namespaces on the Web.  Rather, they are designed to facilitate
   discovery of information on a site when it isn't practical to use
   other mechanisms; for example, when discovering policy that needs to
   be evaluated before a resource is accessed, or when using multiple
   round-trips is judged detrimental to performance.

   As such, the well-known URI space was created with the expectation
   that it will be used to make site-wide policy information and other
   metadata available directly (if sufficiently concise), or provide
   references to other URIs that provide such metadata.
---

I do not believe that this draft utilizes the registry in the way it was designed. In fact, it is set to accomplish the exact opposite, where an unlimited number of resources may be made available within the well-known namespace.

An easy solution would be to create a single well-known resource that will always redirect using an HTTP 3xx response to the actual, non-well-known, URI prefix to be used by the rest of the scheme. This is the approach taken by CalDAV and CardDAV well-known resources defined in [1], after a similar discussion.

Another solution is to use the host-meta well-known document [2] by including a property or link record to the actual prefix, or alternatively, using a URI template to allow more flexibility in the design of such URIs (if that is desired).

Of course, the two proposed solutions add another round trip to the request, at least for the initial one - something the document authors will need to consider in their design and use cases.

EH

[1] http://tools.ietf.org/html/draft-daboo-srv-caldav-10
[2] http://tools.ietf.org/html/rfc6415

> -----Original Message-----
> From: [email-masked] [mailto:wellknown-uri-
> [email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, April 30, 2012 9:00 AM
> Cc: Alexey Melnikov; Barry Leiba; [email-masked];
> [email-masked]
> Subject: [wellknown-uri-review] A .well-known registration for review
> 
> 
> Hi,
> 
> We have a draft [1] that requests a registration of a .well-known URI.
> 
> The core WG are likely to want to use these we think and possibly decade,
> but they're intended to be generally useful as well.
> 
> Barry Leiba is planning to AD sponsor this and Alexey Melnikov will be
> shepherding so if you can cc them as well as the authors on any questions or
> comments that'd be good.
> 
> I hope the plan is to IETF LC this soon, once this review and the uri
> registrations review are done.
> 
> Thanks,
> Stephen.
> 
> [1] http://tools.ietf.org/html/draft-farrell-decade-ni-05
> _______________________________________________
> wellknown-uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wellknown-uri-review

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 May 2012 16:23:18 +0100

Thanks Eran,

> This will be an informal review as I have not received a proper review request using the template and email format specified in RFC 5785.

Sorry 'bout that - will fix it after this.

>    references to other URIs that provide such metadata.

I guess we're not the only ones who skipped over that bit eh;-)

> I do not believe that this draft utilizes the registry in the way it was designed. In fact, it is set to accomplish the exact opposite, where an unlimited number of resources may be made available…

Have to agree, that's a fair cop.

> Of course, the two proposed solutions add another round trip to the request, at least for the initial one - something the document authors will need to consider in their design and use cases.

Need to go and think about that for a bit. Will be back
when that's done... mighn't be long though - for at least
one use-case that'd probably be ok but I need to check
with some folks.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 May 2012 16:34:37 +0100

Hi Eran,

A follow up question.

If we plumped for the 3xx approach now, on the basis that
its simpler, but found out later that the host-meta way of
doing it would be more useful, is there an easy way to
update things so both options would be available, in a
sensible way? (Why do I feel like I'm webfingering:-)

I want to just go for one approach now, but am wondering
if that would need a new registry entry if we wanted to
use the other one later. That wouldn't necessarily be a
problem, I'd just like to know before we make a change
to one or the other.

Ta,
S

---

From: Eran Hammer <[email-masked]>
Date: Tue, 1 May 2012 15:56:43 +0000

The main issue is how to get clients updated to use the other location. If you use host-meta, you don't need any registration, just mint a relation type (registered or uri) and use host-meta to contain this information. If you use the ni well-known location, you need to register that.

My personal preference would be to register the ni prefix and use 3xx to obtain the actual endpoint, unless you think there will be overlap between host-meta identity/authentication/social use cases and this, in which case it will be more effective to reuse host-meta.

EH

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2012 8:35 AM
> To: Eran Hammer
> Subject: Re: [wellknown-uri-review] A .well-known registration for review: ni
> 
> 
> Hi Eran,
> 
> A follow up question.
> 
> If we plumped for the 3xx approach now, on the basis that its simpler, but
> found out later that the host-meta way of doing it would be more useful, is
> there an easy way to update things so both options would be available, in a
> I want to just go for one approach now, but am wondering if that would need
> a new registry entry if we wanted to use the other one later. That wouldn't
> necessarily be a problem, I'd just like to know before we make a change to
> one or the other.
> 
> Ta,
> S
> 
> > This will be an informal review as I have not received a proper review
> request using the template and email format specified in RFC 5785.
> >
> > I have read through the document and have some concerns about its use
> of the Well-Known URI registry. When the registry was created, it was
> explicitly designed not to form a large namespace or allow the creation of
> resource trees within in. Section 1.1 is pretty explicit about this:
> >
> > ---
> > I do not believe that this draft utilizes the registry in the way it was
> designed. In fact, it is set to accomplish the exact opposite, where an
> unlimited number of resources may be made available within the well-
> known namespace.
> >
> > An easy solution would be to create a single well-known resource that will
> always redirect using an HTTP 3xx response to the actual, non-well-known,
> URI prefix to be used by the rest of the scheme. This is the approach taken
> by CalDAV and CardDAV well-known resources defined in [1], after a similar
> discussion.
> >
> > Another solution is to use the host-meta well-known document [2] by
> including a property or link record to the actual prefix, or alternatively, using a
> URI template to allow more flexibility in the design of such URIs (if that is
> desired).
> >
> > Of course, the two proposed solutions add another round trip to the
> request, at least for the initial one - something the document authors will
> need to consider in their design and use cases.
> >
> > EH
> >
> >> The core WG are likely to want to use these we think and possibly
> >> decade, but they're intended to be generally useful as well.
> >>
> >> Barry Leiba is planning to AD sponsor this and Alexey Melnikov will
> >> be shepherding so if you can cc them as well as the authors on any
> >> questions or comments that'd be good.
> >>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 May 2012 17:26:45 +0100

I think I'd also go with 3xx for a first cut. (Asking folks.)

I guess a benefit of host-meta might be that the URI-template
thing, which could allow a way to map to existing things with
hash values in their URLs. I need to look at it some more.

I don't think this is really related to the id/auth/social
stuff directly, its more about the objects (photos,videos)
you might get, be they public or not.

And maybe also javascript etc included from a HTML page
that's been loaded via HTTPS - this could give you a way
improve that mixed content to get at that with name-data
integrity, which could be useful if the browser people
wanted to use it. (I've no idea if they might though, so
that's not too high on the list right now.)

I expect it'll be the end of the week before I've had a
good look at this, but I'll be back to you about then.

Thanks,
S

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 07 May 2012 16:15:42 +0100

> Sorry 'bout that - will fix it after this.
Have you fixed that in -06?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 May 2012 16:19:49 +0100

On 05/07/2012 04:15 PM, Alexey Melnikov wrote:
>>> This will be an informal review as I have not received a proper
>>> review request using the template and email format specified in RFC
>>> 5785.

I have now sent the mail in the required form I believe. This
wasn't a change to the draft but just to the incantation used
in the mail asking for review. If that's still wrong, I'll
just keep trying 'till its fixed;-)

Separately, -06 contains text on using 30x for .well-known/ni
responses that I hope addresses Eran's technical concern, but
I guess we'll see when he gets a chance to respond. (I only
suggested that change a day ago.)

S