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] DNS XRD Discovery proposal


The fragment is important for the Canonical ID of the XRD as it allows for the reuse of the URI without recycling the CID itself.  

However I don't off hand see a reason for trying to preserve it during the mapping of a identifier to a URI for a XRD.  It is never sent on the wire.

On the other hand someone may have a reason I am unaware of.

=jbradley

On 17-Dec-08, at 4:47 PM, Peter Davis wrote:


On Dec 17, 2008, at 9:14 AM, Ben Laurie wrote:

On Wed, Dec 17, 2008 at 1:52 PM, Peter Davis <peter.davis@neustar.biz> wrote:
On Dec 17, 2008, at 5:11 AM, Ben Laurie wrote:

On Tue, Dec 16, 2008 at 9:07 PM, Peter Davis <peter.davis@neustar.biz>
wrote:

I've finally gotten around to adding to the wiki my suggestions on the
use
of the DNS for XRD discovery [1].

I did not get all the example URIs in that i wanted, but thought, given
recent conversation, i should at least demonstrate how DNS would provide
XRD
(and site-meta), and perhaps simplify the XRD location processing a bit.

Not sure why this mentions SMS? Other than that, looks good to me,
though a couple of points:

I clarified in my reply to Brian's similar question.  I will work in an SMS
and a few other non-browser examples over time.

1. Under "Services" you say you will define 1 service, and then go on
to define 2.

I added one mid-writing and forgot to update that sentence.  thanks.

2. The Service is "U2MD+xrd" (for example), but RFC 3403 has them the
other way round: "xrd+U2MD".

Actually, the DNS database specified in 3403 says only:

     SERVICES
     A <character-string> that specifies the Service Parameters applicable
to
     this this delegation path. It is up to the Application Specification
to specify the values found in this field.

the example uses service identifiers before the transform hint (U2MD) in
3403.  the ABNF i supplied is pretty much a clone of RFC3761 (ENUM), so the
pattern sequencing is their fault :-P

I didn't mean to suggest it was wrong, just different from their
examples for no apparent reason.

Fair enough.

3. The examples are perhaps a little too lax, since
http://foo.example.biz/any/url/at/all?abc=def#blah would transform to
https://bar.example.biz/any/url/at/all?abc=def/user-xrd#blah, which
doesn't seem right.

I hinted at that in the draft.  Of course the regex is up to individual
implementations, so if query params and fragment identifiers are
undesirable, NAPTR publishers would accommodate for that.

Of course, but some level of realism might be nice.

makes sense to me.  I'll craft a more meaningful regex.



4. Not clear to me why the #blah gets preserved?

I showed that one deliberately, since it seemed important for some for key
selection and trust processing discussions rooted in [1]

I'm sure it was deliberate, but I still don't understand why it gets preserved.

For that, I'll bow to those discussing the point wrt providerID/Service Provider, who seem to be implying that fragment identifiers are important for key verification and selection.  If I've mis-interpreted their use case, I'm happy to drop the fragment ID.

thanks for all the feedback

=peterd


---------------------------------------------------------------------
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

smime.p7s



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