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