On Wed, Aug 04, 2010 at 10:58:55AM -0400, Iustin Pop wrote: > On Fri, Feb 08, 2008 at 09:00:56AM +0800, [email protected] wrote: > > Package: doc-rfc-std > > Version: 20030621-1 > > File: /usr/share/doc/RFC/links/rfc2616.txt.gz ? > > > > What is up with this crazy paragraph? > > > > 4.If the message uses the media type "multipart/byteranges", and the > > ransfer-length is not otherwise specified, then this self- > > elimiting media type defines the transfer-length. This media type > > UST NOT be used unless the sender knows that the recipient can arse > > it; the presence in a request of a Range header with ultiple byte- > > range specifiers from a 1.1 client implies that the lient can parse > > multipart/byteranges responses. > > > > I.e., ransfer, elimiting, UST, arse, ultiple, lient. > > The pdf is fine. > > This is exactly how http://www.ietf.org/rfc/rfc2616.txt looks like. > > > On Thu, Mar 13, 2008 at 05:35:36AM +0800, [email protected] wrote: > > Many RFCs are damaged, e.g, several places in rfc2516.txt.gz we see > > injury, e.g., > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | VER | TYPE | CODE | SESSION_ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | LENGTH | payload ~ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This is exactly how http://www.ietf.org/rfc/rfc2516.txt looks like, and > that syntax shows a variable length field. > > Given this, I'm inclined to close this bug as invalid.
FYI, I've sent an email to ietf to see if rfc2616 can be corrected. If they don't reply, I'll just apply a local patch. thanks, iustin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
