OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xri] Designating DNS discovery for non-HTTP URIs

How would other existing (or planned) meta-data provisioning methods work with /site-meta? Specifically the three I am thinking of are Site maps (sitemap.xml), XRDs, and XMPP entity capabilities.
Would you see these as alternative formats for the information in /site-meta, or something that people would need to retrieve /site-meta first and then retrieve the particular meta-data format?

From: Eran Hammer-Lahav
Sent: Thu 1/8/2009 11:34 AM
To: Peter Davis
Cc: xri@lists.oasis-open.org; David Orchard; Jonathan Rees; Mark Nottingham
Subject: RE: [xri] Designating DNS discovery for non-HTTP URIs

> -----Original Message-----
> From: Peter Davis [mailto:peter.davis@neustar.biz]
> Sent: Thursday, January 08, 2009 5:17 AM
> To: Eran Hammer-Lahav
> Cc: xri@lists.oasis-open.org; David Orchard; Jonathan Rees; Mark
> Nottingham
> Subject: Re: [xri] Designating DNS discovery for non-HTTP URIs
> On Jan 7, 2009, at 6:40 PM, Eran Hammer-Lahav wrote:
> > There seems to be strong resistance in various communities to the
> > idea that
> > an HTTP server can speak authoritatively for non-HTTP URIs. There is
> > also
> > strong resistance to using DNS as the entry point for resource
> > discovery. At
> > the same time, it is clear we need to support non-HTTP URIs and
> > there is
> > strong desire to include a DNS flavor.
> Can you provide any references to where this resistance is occurring?

To DNS mostly offline. To Site-meta for non-HTTP, see recent W3C TAG F2F notes and posts by Mark N. on www-talk.

> > [snip]
> >
> > But if the resource is not an HTTP resource such as
> mailto:user@example.com
> > ,
> > the consumer must look for a DNS record for the example.com domain
> > identifying an HTTP resource using the /site-meta format with the
> > Link-Template record. Basically, instead of just doing a GET /site-
> > meta, the
> > consumer must first find out where the non-HTTP /site-meta is
> > located. It
> > will usually point to /site-meta (the location) but might not.
> Why just an HTTP resource for /site-meta? What about XMPP clients?
> should they not be able to retrieve XRDs via xmpp:user@example.com via
> RFC3920 as a stanza?

All I am saying is that when you have an HTTP URI, you simply 'GET /site-meta HTTP/1.1' but when you have an XMPP URI you will need to first got to DNS and simply confirm that the DNS admin agrees that /site-meta can speak on behalf of its XMPP URIs.

> > This will ensure that the DNS admin has full control over discovery
> > information of non-HTTP URIs and not the HTTP admin. But it will
> > also allow
> > both HTTP and non-HTTP to use exactly the same /site-meta file and
> > mechanism
> > for most use cases.
> But for implementations where HTTP is not the predominant protocol,
> thus no HTTP/site-meta would normally exist, should we consider
> supporting other candidate transports for the data?  It strikes me
> that this is unnecessarily limiting.

Sure, if there are compelling use cases and entities eager to implement our draft. We have very compelling use cases with immediate applicability for the rest of this solution.

> > The reason the content of the Link-Template isn't placed directly in
> > the DNS
> > record is mostly to keep the discovery workflow as uniform as
> > possible, and
> > to use DNS in the simplest way to increase adoption.
> But does add an extra step in the resolution of the XRD, which should
> be considered against the gains one gets out of such uniformity.

True, but I view the DNS step as more of an authority verification step (not really trust because it is not secure) rather than part of the actual discovery. I am even considering making this more restrictive that the file location must always be /site-meta and the DNS simply allows the DNS owner to officially delegate all discovery to the HTTP admin. Basically something like a record that says "for this domain/sub domain you can use Site-meta as authoritative for all URI types" but not allow you to set a different location for /site-meta. I would also expect many non-identity/security applications to skip this step because they just don't care about the authority question.

> > Thoughts?
> Generally, I agree with this approach modulo my comments.
> >
> >
> > EHL
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> Peter Davis: NeuStar, Inc.
> Director & Distinguished Member of the Technical Staff
> 45980 Center Oak Plaza Sterling, VA 20166
> [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W]
> http://www.neustar.biz/
>   [X] xri://@neustar*pdavis [X] xri://=peterd
> The information contained in this e-mail message is intended only for
> the use of the recipient(s) named above and may contain confidential
> and/or privileged information. If you are not the intended recipient
> you have received this e-mail message in error and any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please
> notify us immediately and delete the original message.

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]