ISO standards have their own hierarchy at 1.0.x, with ISO/8601 as 1.0.8601. Some OID are mentioned in a RFC as part of non-IETF hierarchy, like 1.3.6.1.6.3.1.1.5.1 in RFC 2576 and 0.9.2342.19200300.100.4 in RFC 3001.
Is there a canonical prefix, like the ISO 1.0.x, for RFC documents themselves?
Related
Is there an RFC that recommends or defines some basic features an application protocol should or must contain? I'm thinking of (but not limited to):
The application protocol specification (APS) must have a method to
denote the end of a message (say by length values or end-of-message
characters).
The APS must specify the commands that initiate an action and all and
only the acceptable responses.
The APS must specify the format of each acceptable command and its
related data, if any.
The APS must define how to handle errors such as data that does not match any know command in the APS
(I'm sure there are others)
or, can a RFC-proposed APS contain whatever information it likes? Is it the case that the RFC approval process has these basic APS behaviours/features/properties "internalised" since any reliable APS will need these - and there is no need anywhere to explicitly define these properties/behaviours of an APS?
I am trying to extract all domain names out of COM and NAME dns zone file. Those zone files contain all dns entries and there seem to be lack of information about structure of zone files.
Do all domain registered has NS entries? Even those which are not actively used? Which record/records should I use to extract domain names.
Zone files are very large and sorting them would be stupid idea. So if I can use one DNS record type to extract domain name than it would be easier.
I found this python script(I dont know python) on GitHub which uses only NS entries. Is it correct logically?
Someone with experience please comment.
The format of the DNS zone file is defined in RFC 1035 (section 5) and RFC 1034 (section 3.6.1). You can find many details on Wikipedia: https://en.wikipedia.org/wiki/Zone_file
It contains only the published domain names that is those having at least one nameserver and not being under clientHold or serverHold statuses (see http://www.icann.org/epp#clientHold and http://www.icann.org/epp#serverHold), which means in short it is NOT all domain names registered.
.COM zone file is huge indeed. In any case, you need to match on NS records lines and deduplicate domain names. There are multiple strategies to do that, depending on your constraints.
Note that many providers on line already do this work for you and can provide directly the domain names if this is all you are interested in. Some may also provide differential content, one day from the previous.
What is usage of MB, MG, MR types in a Resource Record?
Some information in Here, but I can't understand their usage in real world!
I believe that those records are obsolete. They were trying to replace some SMTP commands like VRFY and EXPN.
According to the IANA DNS parameters list they were EXPERIMENTAL RR types proposed (before the DNS properly existed) in RFC 883 and specified in RFC 1035.
AFAIK, they've never seen any significant real-world deployment.
Does DBpedia name have any standard or convention? By that, I mean, e.g., United Kingdom has a resource named United_Kingdom. But I'm seeing that the fact of having an underscore and having each word being capitalized doesn't hold. For instance, take University_of_Manchester; if you type it as University_Of_Manchester with a capital ‘O’ in “of,” you won't get the resource. Is it obligatory to do a filtering to get the resource name in the proper case, because we may want to make all letters lowercase, have underscore in spaces and just make a query because doing in filtering in the SPARQL do takes some time.
Any suggestions? I've just started to learn about DBpedia, so I may be missing something.
DBpedia encodes the information available in Wikipedia, and its naming convention is based on the names of Wikipedia articles. The DBpedia wiki page, The DBpedia Data Set, says, in Section 3. Denoting or Naming “Things”:
Each thing in the DBpedia data set is denoted by a de-referenceable IRI- or URI-based reference of the form http://dbpedia.org/resource/Name, where Name is derived from the URL of the source Wikipedia article, which has the form http://en.wikipedia.org/wiki/Name. Thus, each DBpedia entity is tied directly to a Wikipedia article. Every DBpedia entity name resolves to a description-oriented Web document (or Web resource).
Until DBpedia release 3.6, we only used article names from the English Wikipedia, but since DBpedia release 3.7, we also provide Internationalized Datasets that contain IRIs like http://xx.dbpedia.org/resource/Name, where xx is a Wikipedia language code and Name is taken from the source URL, http://xx.wikipedia.org/wiki/Name.
Thus, since the Wikipedia article is University of Manchester, not University Of Manchester, the DBpedia resource is http://dbpedia.org/page/University_of_Manchester, and not http://dbpedia.org/page/University_Of_Manchester.
I'm currently implementing a decentralized DNS, and am wondering if a domain name character limit is specific to the storage of DNS records
According to Wikipedia
The full domain name may not exceed a total length of 255 characters
But then below it also says
In practice, some domain registries may have shorter limits.
I've also looked at this answer here which mentions -
My understanding is that the 255-character limit is to be considered
after the IDNA conversion.
This is because DNS records have this character limit...
Is this true, and if so, does this mean my implementation can resolve domains with larger than 256 chars?
Thi is an RFC document you need:
http://www.faqs.org/rfcs/rfc1035.html
According to this different DNS records has it's own limit.
Probably you shouldn't think about a particular software or different practices, you just should look to an appropriate document (rfc specification).
There are two limits:
255 character total length - this is arbitrary "To simplify implementations" (section 3.1 of RFC 1035)
63 characters per label - this is fixed by the 6 bit length field
There's nothing intrinsic in the wire format of DNS that limits names to 255 characters, but all DNS implementations should support up to that limit and no more.