Re: [xri] DNS XRD Discovery proposal

["Gabe Wachob" <gwachob@wachob.com>]

I distinctly remember that much of the pushback was that NAPTR records
were relatively "new" and that reliance on these RR's would be risky
relative to the ability to deploy.

I have to trust that this is no longer the case. Also, the use here is
less "convoluted" that what I was proposing I think... We were being a
little ambitious back in 2003..

    -Gabe

On Thu, Dec 18, 2008 at 5:07 AM, Peter Davis <peter.davis@neustar.biz> wrote:
> Great circles indeed.  Something has done for us here is the huge increase
> in the use of NAPTR, and support in resolver stacks (which was spotty in
> 2003).  Today, however, between it's heavy use in SIP infrastructures and
> MMS infrastructures, carrier and enterprise support of this RR is pretty
> broad.
>
> Gabe, feel free to tweak my proposal as you see fit, as it is really just a
> strawman at the moment.
>
> =peterd
>
> On Dec 18, 2008, at 1:44 AM, Gabe Wachob wrote:
>
>> I like this thread.
>>
>> We considered using SRV/DDDS waay long time ago for XRI resolution.
>> There were some practical issues we had at the time, and the feedback
>> we got was that it was too complicated.
>>
>> Here's the original DDDS-based proposal (for resolving XRI authorities
>> segments):
>> http://lists.oasis-open.org/archives/xri/200305/msg00062.html
>>
>> It was some confusion and lack of positive feedback that caused me to
>> propose using HTTP as the "protocol" upon which resolution would be
>> built, and the rest is history (of some sort):
>> http://lists.oasis-open.org/archives/xri/200309/msg00000.html
>>
>> I only bring these up because I am amused by the great circles in
>> which this TC has traveled...
>>
>> On Wed, Dec 17, 2008 at 1:42 PM, Peter Davis <peter.davis@neustar.biz>
>> wrote:
>>>
>>> On Dec 17, 2008, at 3:48 PM, Ben Laurie wrote:
>>>
>>>>>>>> 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.
>>>
>>> Ah!  editor error :-)  But i can blame it on a bug in the regex tool I
>>> used
>>> to validate the examples [1].  I'll fix that in my next pass.
>>>
>>> =peterd
>>>
>>> [1] http://gskinner.com/RegExr/
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>
>>
>>
>> --
>> Gabe Wachob / gwachob@wachob.com \ http://blog.wachob.com
>
> Peter Davis: NeuStar, Inc.
> Director & Distinguished Member of the Technical Staff
> 45980 Center Oak Plaza Sterling, VA 20166
> [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W]
> http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterd
> The information contained in this e-mail message is intended only for the
> use of the recipient(s) named above and may contain confidential and/or
> privileged information. If you are not the intended recipient you have
> received this e-mail message in error and any review, dissemination,
> distribution, or copying of this message is strictly prohibited. If you have
> received this communication in error, please notify us immediately and
> delete the original message.
>
>
>



-- 
Gabe Wachob / gwachob@wachob.com \ http://blog.wachob.com