Is there exist rfc ftp specifcation fresher than RFC 959?
There were several extensions to FTP presented in later RFCs (rfc2228, rfc2389, rfc3659, rfc4217 and maybe some more) and they are enough for all current FTP-related needs. The only things not adopted as a standard but relatively wide-spread are implicit FTP on port 990 and Mode Z / compression.
You can see the current status of RFC 959 in the status section at the top. If some later edition of the standard had replaced RFC 959, then there would be an entry "Obsoleted by" like there is an "Obsoletes" line for RFC 765, the previous version of the standard. However, other documents have since "Updated" the document (you could think of it as patches) and the documents are listed in the status section as "Updated by". There have also been a number of independent extensions that did not need to "update" the standard, like RFC 2428. There is no reliably maintained index of such extension specifications besides the general RFC Index maintained by the RFC Editor.
Related
I can't find anything about the subprotocol used with WebSockets. What is the difference between "chat" and "superchat" subprotocol mentioned in the rfc6455 and where can I find the RFC for "chat" and "superchat" or are they just placeholders?
Both protocols don't exist, so there's no actual difference between them.
These "protocols" were just example name for possible Sec-WebSocket-Protocol header values.
It's pretty much the same as using foo and bar as example names, except they chose chat and superchat as example names.
As previously mentioned, those two names were just meant as examples. The protocol header itself is completely optional, but meant to provide a way to document what sort of dialogue/application this connection is supposed to handle.
In what seems to me to perhaps be a bit of over-engineering or premature bureaucracy, the relevant but "non-normative" RFC section in fact goes to length establishing an IANA registry of WebSocket Subprotocols. What seems to confuse people is that chat and superchat are not listed there.
What online resource is the authority for the complete set of ASN.1 definitions for the SNMP data structures used to request and respond with information? I am interested in versions 2c and version 3.
In RFC 3416 Section 3, I have found most of the definitions needed to use version 2c. However, the document has no mention of something that I have found on other resources referred to as the "snmpv2 message". For example, this shows up in the SNMP Programmers Reference Wiki and in the blog post Simple? Network Management Protocol. It's the data structure that contains the community string, so it's role is essential, but I cannot find where the authoritative source (probably an RFC) with an ASN.1 definition.
Similarly, I cannot find any authoritative ASN.1 definitions of SNMPv3 data structures. I found an ASN file in a github repo's test suite, but I cannot find where this information was taken from.
I would appreciate any help locating these. I'm usually a pretty good Googler, but my usual strategies are not turning anything up beyond what I've already linked to.
SNMP v3 message format is defined in RFC3412 page 19 as section 6 as ASN.1.
SNMP v2c reuses most of v1 message format, except defining new message body (PDU). I think that's why in RFC 3416 you don't see all details, because it only mentions the new PDU definitions for simplicity.
You might want to dig ASN.1 documents out of SNMP RFCs:
Base data types, RFC2578
SNMP v2c message, RFC3416
SNMP v3 message, RFC3412
SNMP v3 USM, RFC3414
I have been starting to see uggc/uggcf (rot-13 encoded http/https) links show up in our system.
Are these worth supporting, is there actually a demand for it? The IETF document (link) has not been touched since 2001 and I cannot find much information on them at all.
Is there an area of the world where this is more common? I've only noticed them since we went world-wide.
The document describes it as a method to 'secure' the url as well as the data. What is the value of rot-13 encoding the data if it can be reversed without a key? HTTPS handles all of this, except for the domain itself.
I know this is an old answer but this is an interesting topic so I'll try to answer your question:
The "Encrypted Hypertext Transfer Protocol -- UGGC/1.0" specification, is an April Fools RFC. The IETF releases these almost yearly on 1st April, and ROT13 "encryption" would be pointless, since by knowning the encryption algortihm, you would be able to "decrypt" the message, in this case the URL.
So no, it's not worth supporting, and it does not provide any "serious" protection. The only usage I've seen is in some CTFs or hacking/crypto challenges.
Regarding the syntax of hostnames, answers to questions like this often refer to RFC 1123 and RFC 952, but fail to mention RFC 921 which seems to place additional restrictions on hostnames. There are probably a bunch of later RFCs about the DNS (and IDN) which cover constraints on hostnames handled by the DNS.
There is a lot confusion around the valid syntax of hostnames and hostnames handled by the DNS.
Which RFCs specify the syntax requirements on hostnames and which RFCs specify additional constraints on the hostnames handled by the DNS?
You're correct to cite RFC 1123 and RFC 952, but you've omitted RFC 2181 "Clarifications to the DNS Specification". Specifically ยง11 contains this text:
... any binary string whatever can be used as the label of any resource record.
Since a "hostname" is a domain name that has an A record, this text would appear to allow any valid domain name to also be considered a valid hostname.
A couple of years ago I asked one of the authors of this text whether that was the intended interpretation and he confirmed that it was. However that view is not widely accepted and there is still no universally agreed answer within the DNS community to your question of what makes a legal hostname.
p.s. you've misread RFC 1123 - at no point does it say that 63 and 255 are lower limits on labels and domain names. The 63 limit is actually enforced by the wire format of a DNS label that only reserves 6 bits for the length of a label.
You could take a look at the RFC 1035.
This is a purely DNS based RFC and explains some of these limitations.
Is there a summary anywhere of the protocol difference between the various WebSockets drafts?
The browser support levels are still all over the place, so it is not sufficient just to consider the RFC.
Obviously the Sec-WebSocket-Version changes, and I know the early format was pretty radically different. However, I mean the more subtle changes in the protocol. For example, hybi-10 (v8), in framing, suggests the extended payload length is stored as 16/63, rather than 16/64 in RFC 6455 (v13).
So: is there a summary of changes anywhere?
Alternatively (if we ignore the very early drafts, and the version numbers), is it the case that the protocol is essentially the same, and that the drafts are mainly corrections to the specification text?
The Wikipedia WebSocket lists which browsers support which protocol.
Also, the IETF provides an diff tool that can be used to compare any two RFC draft specifications. For example, to compare WebSocket draft 15 and 17 go here:
http://tools.ietf.org/rfcdiff?url1=draft-ietf-hybi-thewebsocketprotocol-15.txt&url2=draft-ietf-hybi-thewebsocketprotocol-17.txt
Adjust the url1 and url2 addresses to get a diff for arbitrary versions. Note that this will shows you textual differences to the spec and large changes to the spec often happen without corresponding differences on the wire. I suggest searching the diffs for the "Protocol Overview" section and the "Base Framing Protocol" section which show the header summary and the framing diagram respectively.
The biggest difference in the wire protocol occured between Hixie-76/HyBi-00 (HyBi-00 was just a copy of Hixie-76 for starting the new series) and the rest of the HyBi series starting with HyBi-04 (HyBi-17 became IETF RFC 6455). Some of the major changes from the Hixie series to the HyBi series:
In the Hixie-76 protocol, there was a peculiar hash handshake that happened after the handshake headers but before the actual data frames.
In Hixie-76, the frames were prefixed with 0x00 and suffixed with 0xff. There was no way to determine the length of the frame except by receiving/buffering all the way to the end of the frame. In the HyBi series (after HyBi-00) the frame length is part of the prefix/header and there is no suffix.
The HyBi series supports both UTF-8 text and binary data in the payload (Hixie only supported UTF-8). This is indicated by and opcode in the frame header.
To add a specific change; in Sec-WebSocketVersion <= 8, the origin is in Sec-WebSocket-Origin; however, in 13 this changes to the Origin header. This changes specifically between hybi-10 and hybi-11, which are both version "8" implementations. Also note that it is Origin in hixie-76/hybi-00, so it looks like it went from Origin to Sec-WebSocket-Origin and then back to Origin.
I'm not aware of many of the protocol versions being in current use. I have a websocket server which supports Hixie-76 and hybi-10 through 17 (just changes in Sec-WebSocket-Version) which works against Safari (desktop + iOS), Firefox and Chrome.
(The older) Hixie-76 is useful for talking to iOS devices at least.
hybi-10 onwards are essentially the same. I'd assumed that your example of the extended payload being advertised as 63 bits in hybi-10 was a typo and was one of the many small corrections made when the drafts moved rapidly from 10 to 17.
Later: edited to show that some Safari versions actually use Hixie-76