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


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]