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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@xxxxxxxxx On Sat, Mar 3, 2012 at 11:39 AM, Hector <sant9442@xxxxxxxxx> wrote: > � wrote: >> >> On 3 mar 2012, at 16:56, ned+ietf@xxxxxxxxxxxxxxxxx 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 > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf