Re: [dnsext] URI RRTYPE review - Comments period end Aug 15th

[Phillip Hallam-Baker <[e-mail]>]

Reading the comments, i was seeing the claim made that this is limited to new protocols.

I think we can make all these enhanced discovery schemes more useful if we have a common means of advertising the availability of one or more upgrades in band. And this is better than tying a web service to just one enhanced discovery mechanism.

In other words, this is not a defect, it is the better way to do things. 



Sent from my iPad

On Oct 22, 2010, at 7:43 AM, Patrik Fältström <[e-mail]> wrote:

> 
> On 12 okt 2010, at 15.30, Phillip Hallam-Baker wrote:
> 
>> I have an initial draft out, but I am still working on the details. The
>> practical significance of this is that it is not necessary for the use of
>> the URI scheme to be hardwired into the application protocol as Patrik
>> states.
> 
> Philip, I am not hardwiring any URI scheme. This is the key part of the application:
> 
>> The URI RR has service information encoded in its ownername.  In
>> order to encode the service for a specific owner name one uses
>> service parameters.  Valid service parameters used are either
>> Enumservice Registrations registered by IANA, or prefixes used
>> for the SRV resource record.
> 
> I.e. in the example in the draft, the http in the owner is not there due to the fact the string http is one of the URI schemes that one might get back when looking up _http._web, but because the http and web type/subtype says http is one of the uri schemes one might ge bad in the resolution step.
> 
>> $ORIGIN example.com.
>> _http._web    IN URI 10 1 "http://www.example.com/"
> 
>   Patrik
>