[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] DNS XRD Discovery proposal
On Wed, Dec 17, 2008 at 7:47 PM, Peter Davis <peter.davis@neustar.biz> 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. Sorry, not being clear. AFAICS your regex does not preserve it, so it seemed to get preserved by magic. I am asking about the nature of that magic. > > thanks for all the feedback > > =peterd > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]