问题标签 [rfc]

我正在为一个自学 Ruby 项目滚动我自己的 IP 数据包，并且需要计算 IP 标头校验和（如 RFC 791 p.14 中所述）。当我在这里输入我的问题时弹出的一个相关问题将我指向 RFC 1071，所以我可能大部分都在那里，但只是为了添加到 Stack Overflow，任何人（可能是 Future Josh）都可以提供一些 Ruby 代码用于计算校验和，假设以下 Ruby 位：

常量在文件顶部定义，但如果您正在查看 RFC791 p.11，它们应该是不言自明的。

我正在寻找以下之一： - ATA-4 规范 - 以实模式汇编 (MASM/TURBO ASM) 编写的 ATA-4 规范的包装器

我想更好地理解 RFC 2396 和整个 URL / URI 的东西，并且由于 Cocoa 的 NSURL 基于 RFC 2396，我寻找一个概述。RFC 本身对我来说太难阅读了。

我对 Apple 关于 NSURL 类的文档感到困惑。

在 NSURL 中，他们说：

• NSURL 理解 RFC 1808、1738 和 2732 风格的 URL
• NSURL 理解 RFC 2396 风格的 URI

他们还说 RFC 2396 URI 是路径。

现在这里有什么不同？路径不也是 URL 吗？我的意思是，这是一个位置还是不是？

当用户登录时，我正在尝试将会话 cookie 设置为仅限于特定路径（比如说/foo）。复杂之处在于登录页面已打开/，但请求会立即重定向到/foo/something. 像这样的东西：

要求：

回复：

但是，我可以找到的 RFC 的相关位（rfc2109和rfc2965）是这样说的：

为防止可能的安全或隐私侵犯，如果以下任何一种情况属实，用户代理将拒绝 cookie（不应存储其信息）：

• Path 属性的值不是 request-URI 的前缀。

...

上面描述的 cookie 设置过程似乎可以正常工作，但据我所知，RFC 说不应该。

我想在生产系统中使用它，但如果我以后要面对可怕的浏览器不兼容问题，我真的不想这样做。

我是否误读了 RFC？

提前致谢！

作为一个学习练习，我正在编写一个 Python 程序来连接到 IRC 网络上的通道，这样我就可以将通道中的消息输出到标准输出。我正在使用 asynchat 并手动发送协议消息，而不是使用诸如 Twisted 之类的东西或来自网络的现有机器人代码 - 同样，这是一种更有用的学习体验。

我可以很高兴地发送 JOIN 和 USER 命令，并且可以根据需要 PING/PONG。但是，我注意到在打开 6667 端口的套接字时，我会收到一些消息：

即使我还没有发送 JOIN/USER 命令。

那么，是否在任何地方指定了通知的打开顺序？据我所见，RFC 没有指定在客户端发送 JOIN 命令之前发生什么特别的事情，我不确定在发送 JOIN 命令之前是否等待收到这些通知，如果是这样如何检测我已收到所有通知？

我正在编写一些代码来解析转发的电子邮件。我不确定是否有一些 Python 库、一些我可以坚持的 RFC 或一些其他资源，这些资源可以让我自动完成任务。

准确地说，我不知道转发电子邮件的“布局”是否包含在某些标准或建议中，或者它是否已经经过多年发展，所以现在大多数电子邮件客户端都会为文本部分生成类似的输出：

- 并为附件疯狂（以及任何其他 MIME 部分可以在那里）。

如果它仍然不够精确，我会澄清它，只是我不是 100% 确定要问什么（RFC、Python lib、约定或其他）。

MIME 实体是否有通用 MIME 类型之类的东西？根据 RFC 2045/2046，MIME 实体由标题部分、后跟空行和正文部分（以 CRLF 行结尾）组成。

一个例子可能如下：

换句话说，对于诸如 message/rfc822、单个 multipart-part 等内容是否存在 MIME“超类型”？

我发现 IMAPv4 有一个缺点，因为它迫使用户下载整个正文（文本/HTML + 附件）。

如何编写和提出 RFC 来解决这个问题？

如果您以前有过编写技术文档、提案，尤其是 RFC 的经验，请分享。

我有一个自定义构建的 Unix 操作系统。

我的任务：向操作系统添加IPSec 。

我正在第一阶段工作，完成了前 2 个数据包的发送。

我现在要做的是制作识别有效载荷。我一直在阅读RFC 2409（附录 B），其中讨论了密钥材料（SKEYID、SKEYID_d、SKEYID_a、SKEYID_e 和IV制作）。

现在，我使用SHA-1进行身份验证，因此我使用 HMAC-SHA1，我的加密算法是 AES-256。真正的问题是 RFC 对我应该如何处理PRF不够清楚。它说：

“由于本文档采用的 PRF 反馈机制，使用协商的 PRF可能需要扩展 PRF 输出。”

我使用 SHA-1，这是否意味着我不协商 PRF？

在我看来，AES 是唯一需要扩展的算法（256 位的固定长度），那么，我只需要扩展 SKEYID_e 吗？

如果您碰巧知道更清晰但可靠的来源，请在 RFC 中发布链接。