Re: provisioning software, was DNS RRTYPEs, the difficulty with

[Donald Eastlake <[e-mail]>]

Hey, if people don't like the restrictions of the TXT RR, have I got
an answer for you!
See http://tools.ietf.org/html/draft-ietf-dnsind-kitchen-sink-02
A little out of data but gives you a wide variety of formats :-)

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]



On Sat, Mar 3, 2012 at 11:39 AM, Hector <[e-mail]> wrote:
> � wrote:
>>
>> On 3 mar 2012, at 16:56, [e-mail] wrote:
>>
>>> Doubtful. If a record needs to have, say, a priority field, or a port
>>> number,
>>> given the existence of MX, SRV, and various other RRs it's going to be
>>> very
>>> difficult for the designers of said field to argue that that should be
>>> done as
>>> ASCII text that has to be parsed out to use.
>>
>>
>> Agree with you but too many people today "just" program in perl och python
>> where the parsing is just a cast or similar, and they do not understand this
>> argument of yours -- which I once again completely stand behind myself.
>
>
> The original version of Sender-ID (Caller ID Policy) was an XML version of
> SPF. In fact, the experimental record still exist:
>
>   nslookup -query=txt _ep.hotmail.com
>
>   "<ep xmlns='http://ms.net/1' testing='true'>
>    <out><m><indirect>list1._ep.hotmail.com</indirect>
>    <indirect>list2._ep.hotmail.com</indirect>
>    <indirect>list3._ep.hotmail.com</indirect></m></out></ep>"
>
> It was introductions like this that raised eyebrows and the need to include
> a new RR type with the simpler language SPF TXT fallback for SPF and
> SENDER-ID.
>
> If TXT becomes the acceptable norm, than perhaps the XML format cane easily
> be reconsidered for a DNS TXT storage with a common XML I/O construct. :(
>
> --
> HLS
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf