hallam at gmail.com
Sun Apr 8 14:45:41 PDT 2012
OSI connectionless transport services on top of UDP Applicability
Statement for Historic Status
It may be that there is a fully defined spec somewhere, but what is
the status and does practice really agree with the spec? Is there any
secret sauce that should be documented?
If the answer to all the above is that we are OK then lets go with this option.
All we really need from an archive format is a way to package up all
the files to make submission easy. It could just as easily be a .zip
or a .tar or even multiple entries in an HTML form.
The only function I see as making an archive format essential is to
serve as a hub onto which tools can be hooked. So if someone is
writing a front end to the RFC series or the drafts they only need to
generate or process one format.
On Sun, Apr 8, 2012 at 4:39 PM, Paul E. Jones <paulej at packetizer.com> wrote:
>> One option that is supported in some browsers at least is to use MIME
>> archive format.
> I was wondering about this option, myself. It would perhaps enable something
> people would not want, that being that multiple pages could appear in one
>> Email messages already contain HTML text and embedded images in one file.
>> The only problem being that the format is really not properly specified as
>> a standard and it is BASE64 based so not wonderfully efficient.
> Are you saying RFC 2556 is not well specified, or something about the way
> email clients do it?
>> It really should be possible to exchange HTML+ graphics objects in one
>> data blob. This would be useful IETF work even if IETF does not end up
>> using it for RFCs.
> I think the <img src="data:..."> option thrown out by Joe Hildebrand is a
> good way to do this.
More information about the rfc-interest