On Jul 17, 2014, at 3:49 PM, John C Klensin <john-ietf@xxxxxxx> wrote: > --On Thursday, July 17, 2014 14:38 -0700 "Murray S. Kucherawy" > <superuser@xxxxxxxxx> wrote: > >>>> Specifically referring to Section 3 of >>>> draft-ietf-appsawg-nullmx-05, there is not such thing as a >>>> "NULL MX Resource Record". There is only an MX Resource >>>> Record that this specification proposes to use with a >>>> convention involving specific content in the DATA. One >>>> could call that many things, but "NULL MX Resource Record" >>>> isn't one of them. >>> >>> By my reading of that section, it is defining the term, if >>> only by virtue of the way it is used in the name of that >>> section. >>> >>> Perhaps your confusion would be resolved if the term had a >>> comma in it, so: NULL, MX Record? >>> >>> In other words, NULL is an adjective within the term. > > I don't want to get into grammatical hair-splitting if that can > be avoided, but the current construction names an RR type that > doesn't exist and punctuation doesn't help. As I said, if we > didn't already have a use problem with DNS terminology, it would > be a non-issue. > >>> If you would prefer a different term, please suggest one. > > That particular problem would be easily solved by saying > > "MX Resource Record with a null value" > > or even > > "MX Resource Record that, by convention, points at the root" Agreed. Null as a term is misleading since these MX record contain an a value that simply won't resolve an address because it points to root. Although first used in defining SRV RR where: "A Target of "." means that the service is decidedly not available at this domain." Perhaps using the term 'nullified' as in Nullified MX record would be closer to what this is attempting to communicate. It also seems unlikely anyone would feel a need to capitalize Nullified because it looks like a defined language variable. If only RFC2782 said "A Target of "." means that the service has been nullified and declared not available at this domain." Regards, Douglas Otis > The latter is a little long for a section title, but it exactly > reflects what is going on. I would still like a consensus > opinion from DNSOP both generally and for the specific reason > that a reasonable person might assume that a resource record > with a null value would have an empty DATA field, not one with a > value, even a value pointing informally at the root, so the > question of whether the DNS Experts find "null value" > problematic is actually important. I can't remember whether > resource records with a zero-length DATA field are even allowed, > but we should know for certain before throwing terms like "null > value" around. And, whether this document can, procedurally, > define "null value" as meaning something different from what it > might mean elsewhere in the DNS (were that the case) that would > be, IMO, a Really Bad Idea. > >> I mentioned this to one of the co-authors privately, but since >> you just reminded me of it, I'll mention it here too: >> >> The use of NULL (i.e., in all-caps) makes me think of it more >> as either an acronym or a mnemonic. For example, in C, the >> special pointer with address zero is written in prose as "the >> null pointer", but in source code simply as "NULL". Since >> this draft is more prose than code, my sensibilities would >> prefer it be written as "null" in this document rather than >> "NULL". In its current form, I might expect to find a special >> RR type definition for NULL MX and/or corresponding >> definitions in the appropriate C header files. > > Yes, exactly. That isn't, IMO, the problem, but it certainly > makes it worse (more confusing). See above. > >> This is not a major point since I'm the only one to mention it >> so far, but there you have it. > > Consider it as getting an extra mention. Ultimately, the text > should be clear whether caps are used or not, but the use of the > caps in these contexts doesn't make things any easier. > > john >