[rfc-i] Use of PDF/A for archiving RFC's

Joe Touch touch at isi.edu
Wed Mar 21 15:19:41 PDT 2012


Hi, Leonard,

Yes, I forgot to state that the formats need not be the same; the only 
strict requirement is that we can navigate from one format to another 
using widely available tools (in most cases; in some, such as in the 
editor's role, it's OK that the tools not necessarily be widely available).

Regarding other items you propose for the archival format:

	- authenticity
	this can be achieved many ways, not necessarily inside the
	format itself (e.g., an external thumbprint, such as MD5 sum)

	- metadata
	this is necessary, but need not be in the same format or even
	the same document as the RFC itself

FWIW, I'm the one who uses Word to generate RFCs currently; I don't use 
XML because the editors are too cumbersome. Not to say I support that as 
any particular format, but I'd be very happy if the author format 
supported the use of a "modern WYSIWYG" editor. That's my personal 
preference, though, so I didn't list it as a requirement.

Joe

On 3/21/2012 3:12 PM, Leonard Rosenthol wrote:
> Joe - I think those are a great starting point for requirements.
>
> I just want to point out, as I did in my presentation, that I don't
> believe that a "one size fits all" is necessary.  Meaning that the
> authoring format need not necessary be the archival format.  In fact, I
> would say that it's important that they are NOT the same format because
> (as you are doing below), the requirements for each differ.
>
> For example, I would add to the Archive item some items that aren't
> necessary during the editing process:
> - Guarantee of authenticity
> 	How do you know that a given RFC is really the approved version from the
> IETF?
> - Metadata
> 	Information about authors, rights, history, etc. in a standard
> machine+human readable format
>
> Leonard
>
> On 3/21/12 2:43 PM, "Joe Touch"<touch at isi.edu>  wrote:
>
>> Hi, all,
>>
>> It might be useful to understand the requirements, and separate out the
>> phases since each might have different requirements. Paul notes below a
>> display requirement for the archival version. Some others that come to
>> mind.
>>
>> Since I won't be at the IETF, my view of the phases and some possible
>> requirements is:
>>
>> (this isn't intended to be complete or definitive, but as a suggestion
>> for discussion):
>>
>> ------------
>>
>> Authorship
>> - supported by editors on a wide variety of platforms
>>
>> Editing/community review
>> - supports document comparison ("diffs" or equivalent)
>> - supports copy/paste into email on a wide variety of platforms (e.g.,
>> for email-list conversations about content)
>> 	this might include copy/paste of text as text for email,
>> 	or copy/paste of diagrams as GIF or JPGs for email
>>
>> Submission
>> - can be verified compliant using automatic tools/programs
>> - can be modified (i.e., editable; arguably this means the submission
>> format is either the same as the authorship one or can be easily
>> translated into a format that can be edited)
>>
>> Archive
>> - displays on a wide variety of devices
>> - supports both intradocument and multi-document search (i.e., searching
>> the entire RFC series)
>> - stability measured in decades
>>
>> -------------
>>
>> On 3/21/2012 2:24 PM, Paul Hoffman wrote:
>>> Greetings again, Leonard.
>>>
>>> One common problem with PDF/A is that some display systems cannot
>>> render the results from some PDF/A writers because there is disagreement
>>> about what the spec says or means, and many systems try to be
>>> bug-compatible with others.
>>>
>>> Are there any widely-accepted test systems that will evaluate a PDF/A
>>> file and say whether it is conformant to the standard and, if not, where
>>> it failed conformance?
>>>
>>> --Paul Hoffman
>>>
>>> _______________________________________________
>>> rfc-interest mailing list
>>> rfc-interest at rfc-editor.org
>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>


More information about the rfc-interest mailing list