[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: First steps...Re: IANA type code registration clean up
> At 14:42 -0400 6/13/07, Andrew Sullivan wrote:
>
> >Yes, I am volunteering. Do you have some pointers that I should go
>
> Oh, and I heard that...
>
> First steps before trying to cut English is to agree on what types
> need a few words and what to say.
>
> Here are the type values that I think don't quite add up. Perhaps
> there are more - I was merely looking to see if there were documents
> that support the general knowledge of the type. When I say IANA
> should do something or doesn't list something, I am referring to the
> dns-parameters web page.
>
> 11 - WKS is widely rumored to be dead, but I can't find a document to
> back that up. (I suppose other types are as dead, but no
> documentation.)
RFC 1123 deprecates its use w/o deprecating it.
2.2 Using Domain Name Service
An application SHOULD NOT rely on the ability to locate a WKS
record containing an accurate listing of all services at a
particular host address, since the WKS RR type is not often used
by Internet sites. To confirm that a service is present, simply
attempt to use it.
and
5.2.12 WKS Use in MX Processing: RFC-974, p. 5
RFC-974 [SMTP:3] recommended that the domain system be queried
for WKS ("Well-Known Service") records, to verify that each
proposed mail target does support SMTP. Later experience has
shown that WKS is not widely supported, so the WKS step in MX
processing SHOULD NOT be used.
The following are notes on RFC-822, organized by section of that
document.
> 14 - IANA should mark this as EXPERIMENTAL as per 1035.
> 16 and 17 - these are the two types in RFC 1002 that conflict with
> the TXT and the RP types.
No. 32 (NIMLOC) and 33 (SRV) are the conflicting types.
From RFC 1002
Symbol Value Description:
NB 0x0020 NetBIOS general Name Service Resource Record
NBSTAT 0x0021 NetBIOS NODE STATUS Resource Record (See NODE
STATUS REQUEST)
> 23 - NSAP-PTR is blank, presumably that is meant as a "ditto" to the
> previous line.
> 31 and 32 - EID and NIMLOC have no document to define them.
> 34 - IANA's reference is an email address that is out of date.
> 38 - IANA doesn't list 3363 which moved A6 to experimental.
> 40 - SINK has no defining document listed.
> 100-103 - no explanation why these are IANA reserved are documented.
>
> I am sure we can consider other types dead or in a vegetative state,
> like X25, but my goal here is just to make sure that if you are told
> to implement a DNS protocol speaking element, you have access to a
> complete specification, not necessarily a sensible specification.
>
> I'm sure that the "problems" with types 14, 23, and 38 are just
> editorial moves needed on the web page.
>
> I am only "excited" about the conflicting definitions of types 16 and
> 17 because the types that we don't recognize are defined in a
> document that has attained "STD" status.
>
> Are there other types people would like to see treated?
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis +1-571-434-5468
> NeuStar
>
> Sarcasm doesn't scale.
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>