Group Notebook - page 31 of 42

Added Tue Apr 7 01:50:35 1998 (GMT) Jim Myers

Revised Draft DOE2000 Notebook Export Format Specification

DOE2000 Electronic Notebook Export Format Specification

(based on Noel's Perl code, the NOb spec, discussions about NObLists at the DOE2000 meeting, etc.)

General Format

The Archive is composed of a header followed by one or more NObs, each composed of multiple NOb fields.

Each NOb is contiguous.

NObs are only nested as the content of NObs of dataType "application/NObList"

Lines/fields denoted by [ ] are optional

The ordering of certain lines is not important:

The "From:...", "To:...", "Date:...", and "Subject:..." lines in the header
"Content-*:..." lines in a single MIME block
Ordering of top level NObs
Ordering of EN-fields within a NOb

Header information:

From DOE2000 Notebook <date>
[
From: <notebook name><notebook type>
To: Notebook Archive
Date: <fulldate>
Subject: DOE2000 Notebook Export
]
MIME-Version: 1.0
Content-type: multipart/mixed; boundary ="==<random1>=="
Content-Transfer-Encoding: 7bit
X-ENArcMIME-Version: 1.1
<blankline>

For each top level NOb:

--==<random1>==
Content-NOb-Num: <n>
Content-NOb-Rev: <m>
Content-type: multipart/parallel; boundary="==<randomn>=="
Content-Transfer-Encoding: 7bit
X-NOb-Version: 1.1
<blankline>

For each NOb field:

--==<randomn>==
Content-NOb-Field: <fieldname>
Content-Type: <MIME-type>[; charset]
Content-Disposition: attachment; filename="<fieldname>"
Content-Transfer-Encoding: <encoding>
Content-Length: <contentlength>
[<Content-*>] <blankline>
<content>
--==<randomn>==-- --==<random1>==--

Definitions

Variable	Format	Example
<date>	Day Mon Date Hr:Min:Sec Year	Mon Jan 26 20:40:10 1998
<fulldate>	Day, Mon Date Hr:Min:Sec Year +0000 (GMT)	Mon, 26 Jan 1998 20:40:10 +0000 (GMT)
<notebook name>	A user specified name for their notebook	Noel's Flying Circus
<notebook type>	A standard description of the engine type	ORNL DOE2000 Notebook
<random1>	a separator string unique from all other separators used in this file	356163058429956
<randomn>	other distinct separator strings unique within the enclosing block	separator5
<blankline>	an empty line	"\r\n"
<n>	sequential non-negative number	3
<m>	non-positive number	0
<fieldname>	the name of a NOb field	AuthorName
<MIME-type>	The MIME type of this NOb field	text/plain
[; charset]	optional character set for text fields	charset=us-ascii
<encoding>	The encoding used for this field	quoted-printable or base64
<contentlength>	The length of the <content>	13
<content>	The actual NOb field data	Elmer P. Fudd
<[Content-*]>	Many other Content-* headers are possible and may be inserted by some MIME generators. If they exist, they will be ignored by the notebook engines. (any data relevant to a notebook engine should be included as a separate NOb-field)	Content-Description

Standard Encodings for NOb fields

This table defines how NOb fields should be encoded and written to the archive file.

Required
NOb Field	MIME-type	Meaning	Interpretation	MIME Encoding
<authorName>	text/plain	author's full name		quoted-printable
<objectID>	text/plain	an engine specific ID string for this NOb	engine specific	quoted-printable
<dateTime>	text/plain	the date and time of NOb creation	dd MMM H:m:s zzz yyyy (e.g. 26 Dec 22:43:19 EDT 1992, see Java1.1 SimpleDateFormat class for meaning)	quoted-printable
<label>	a user defined summary of the NOb	text/plain	user defined	quoted-printable
<dataType>	text/plain	the MIME type/subtype of the NOb data field	MIME type for notebook engine interpretation of the NOb data	quoted-printable
<data>	data dependent, may be <dataType>	the data itself	for a generic MIME reader: data of type <data dependent> for a notebook engine: dat of type "dataType"	see table below
<dataRef>	text/plain	a URL to the original data	a standard (e.g. http://...) or notebook specific (e.g. EMSLarchive://...) URL	quoted-printable
Optional
<objectRevision>	text/plain	non-positive number	current revision is "0", previous revisions are "-1", ..., "-n"	quoted-printable

Recommended Standard Encodings for various MIME types (for "data" field)

Separators of the form ==random== are only guaranteed to work if all data is encoded as quoted-printable, base64, or some other format in which "==" is not a legal string. Thus this specification requires that all content be encoded as quoted-printable or base64. The encodings below are recommendations, but engines should be able to parse data encoded with the alternate format.

MIME-type	MIME Encoding
text/plain	quoted-printable
text/html	quoted-printable
image/*	base64
application/x-EN-NObList	quoted-printable
application/*	base64
/	base64

Standard Notebook Engine Interpretation for non-standard MIME types (for "data" field)

This table defines the encoding of the content of non-standard MIME types.

MIME-type	MIME Encoding
application/x-EN-NObList	--==<randomn>== Content-NObList: <n> Content-type: multipart/parallel; boundary="==<randomn'>==" Content-Transfer-Encoding: 7bit X-NObList-Version: 1.1 Content-Disposition: attachment; filename="NObList" Content-Length: <contentlength> <blankline> [<individual NObs in list, separated by --==<randomn'>==> --==<randomn'>==--] --==<randomn>==--

Jim Myers

Group Notebook - page 41 of 42

Modified Mon Oct 26 20:47:52 1998 (GMT) Elena Mendoza
Added Mon Oct 26 20:46:40 1998 (GMT) Elena Mendoza

Additions/Changes to the Export MIME spec

These are the results of our discussion on 10/26/98.  
  
We will use X-EnArcMime as it is a mail header and used once.   
We will use Content-NOb-Version etc since these are MIME headers.  
  
We will keep the top line of the header as From DOE2000 Electronic Notebook etc.  
The next line can be a reference to the individual notebook that this archive  
came from.  
  
We all should handle any number of blank lines in the file.  
  
As per mail/mime specifications we should be able to ignore any text that occurs  
in between the end of a boundary and the beginning of the next boundary.  
  
The date/time NOB field should continue to be the Java format in ENGLISH. However  
we will standardize on the UTC version instead of timezone specific.  
  
We should all ignore extra fields (ie. the EnArcField from ORNL) if they don't apply  
to our implementation.  We agreed however to keep each other informed if we   
are going to create other fields such as these.  
  
We are modifying the spec so specify that the label field should be relatively  
short and only one line.  The individual clients have permission to cut this  
label as short as is needed for display.  
  
An additional optional field was added to the spec.  It will be called "description" 
  
Thats all,  Please check for a "full" spec that is up to date soon.  
  
Elena