Re: [dnsext] URI RRTYPE review - Result [IANA #376037]

[Patrik Fältström <[e-mail]>]

Thanks for your work Fred!

   Patrik

On 18 feb 2011, at 00.16, Frederico A C Neves wrote:

> Dear Colleagues,
> 
> This message ends the review process for the URI RRTYPE, according to
> my judgment it meets both requirements of section 3.1.1 and none of
> section 3.1.2 of RFC5395 and should be accepted.
> 
> Best Regards,
> Frederico Neves
> 
> On Thu, Jan 27, 2011 at 11:43:20AM -0200, Frederico A C Neves wrote:
>> Dear Colleagues,
>> 
>> Bellow is a resubmission of a completed template requesting a new
>> RRTYPE assignment under the procedures of RFC5395.
>> 
>> This message starts a 3 weeks period for an expert-review of the DNS
>> RRTYPE parameter allocation for URI specified in
>> http://tools.ietf.org/html/draft-faltstrom-uri-05
>> 
>> If you have any new comments regarding this request that have not yet
>> being made at the thread starting with message
>> http://www.ietf.org/mail-archive/web/dnsext/current/msg08956.html ,
>> please post them here before Feb 17th 18:00 UTC
>> 
>> Best Regards,
>> Frederico Neves
>> 
>> --begin 5395 template URI--
>> A.   Submission Date:
>> 
>>     May 23, 2009
>> 
>> B.   Submission Type:
>> 
>>     [X] New RRTYPE
>>     [ ] Modification to existing RRTYPE
>> 
>> C.   Contact Information for submitter:
>> 
>>     Name: Patrik Faltstrom
>>     Email Address: [e-mail]
>>     International telephone number: [phone]
>>     Other contact handles:
>>     (Note: This information will be publicly posted.)
>> 
>> D.   Motivation for the new RRTYPE application?
>> 
>>     There is no easy way to get from a domain name to a URI.  Some
>>     mechanisms exists via use of the NAPTR [RFC3403] resource
>>     record.  That implies quite complicated rules that are
>>     simplified via the S-NAPTR [RFC3958] specification.  But, the
>>     ability to directly look up a URI still exists.  This
>>     specification uses a prefix based naming mechanism originated in
>>     the definition of the SRV [RFC2782] resource record, and the
>>     RDATA is a URI, encoded as one text field.
>> 
>>     See also Section 1 in draft-faltstrom-uri-05.txt.
>> 
>> E.   Description of the proposed RR type.
>> 
>>     The format of the URI resource record is as follows:
>> 
>> 
>>     Ownername TTL Class URI Priority Weight Target
>> 
>> 
>>     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.
>> 
>>     The wire format of the RDATA is as follows:
>> 
>> 
>>                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |          Priority             |          Weight               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    /                                                               /
>>    /                             Target                            /
>>    /                                                               /
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> 
>> F.   What existing RRTYPE or RRTYPEs come closest to filling that
>>     need and why are they unsatisfactory?
>> 
>>     The RRTYPE that come closest is the NAPTR resource record.  It
>>     is for example used in the DDDS and S-NAPTR algorithms.  The
>>     main problem with the NAPTR is that selection of what record (or
>>     records) one is interested in is based on data stored in the
>>     RDATA portion of the NAPTR resource record.  This, as explained
>>     in RFC 5507 [RFC5507], is not optimal for DNS lookups.  Further,
>>     most applications using NAPTR resource records uses regular
>>     expression based rewrite rules for creation of the URI, and that
>>     has shown be complicated to implement.
>> 
>>     The second closest RRTYPE is the SRV record that given a
>>     prefixed based naming just like is suggested for the URI
>>     resource record, one get back a port number and domain name.
>>     This can also be used for creation of a URI, but, only URIs
>>     without path components.
>> 
>> G.   What mnemonic is requested for the new RRTYPE (optional)?
>> 
>>     URI
>> 
>> H.   Does the requested RRTYPE make use of any existing IANA Registry
>>     or require the creation of a new IANA sub-registry in DNS
>>     Parameters?
>> 
>>     Yes, partially.
>> 
>>     One of the mechanisms to select a service is to use the
>>     Enumservice Registry managed by IANA.  Another is to use
>>     services and protocols used for SRV records.
>> 
>> I.   Does the proposal require/expect any changes in DNS servers/
>>     resolvers that prevent the new type from being processed as an
>>     unknown RRTYPE (see [RFC3597])?
>> 
>>     No
>> 
>> J.   Comments:
>> 
>>     None
>> --end 5395 template URI--
>> _______________________________________________
>> dnsext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsext

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext