[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] DNS XRD Discovery proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]