Re: Draft progression

Martijn Koster <m.koster@nexor.co.uk> Fri, 26 August 1994 10:37 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01034; 26 Aug 94 6:37 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01030; 26 Aug 94 6:37 EDT
Received: from mocha.Bunyip.Com by CNRI.Reston.VA.US id aa02970; 26 Aug 94 6:37 EDT
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24583 on Fri, 26 Aug 94 05:50:47 -0400
Received: from [128.243.6.3] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24576 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Fri, 26 Aug 94 05:50:22 -0400
Message-Id: <9408260950.AA24576@mocha.bunyip.com>
Received: from nexor.co.uk (actually host victor.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (PP); Fri, 26 Aug 1994 10:50:11 +0100
To: Alan Emtage <bajan@bunyip.com>
Cc: Markus Stumpf <stumpf@informatik.tu-muenchen.de>, m.koster@nexor.co.uk, iafa@bunyip.com
Subject: Re: Draft progression
In-Reply-To: Your message of "Thu, 25 Aug 1994 22:50:39 EDT." <9408260250.AA23466@mocha.bunyip.com>
Date: Fri, 26 Aug 1994 10:50:02 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martijn Koster <m.koster@nexor.co.uk>

Wow, things are moving fast, half the things I was going to suggest
are fixed already! Thanks Alan, also for making me co-author.

Administrative: From tonight 18:15 I won't be online till Tuesday
morning...

> > We are now at about 6200 template files with various draft levels :/
> > We will have to convert them all, too :/

Markus, if you need a script to do that one one file system let me know...

> > But I think we should get as much changes as possible in the next draft.
> > If we'll find some time within the next week to have some discussion on
> > the interesting points, we could get it in the next draft. I don't know
> > of any other site/institution besides our FTP-server and Martijn's ALIWEB
> > that use IAFA currently, so the changes should not do any harm to others.
> > And I think it's better and easier to change it now than later.
> 
> Fine.... if the group is OK with that then I don't have any problems with
> it.

Absolutely -- that's what it's a draft for.

> Done. I have converted all "SERVICES" to "SERVICE" and made the above
> changes.

Incidentally, ALIWEB already uses 168 SERVICE records, and only
has one SERVICES record, so I'm fine. :-)

> > 1) could we please make URI a variant field and allow it to be a shorthand
> >    for Access-Host-Name, Access-Host-Port, Access-Method and Location?
> 
> Done. I have removed Access-Host-Name, Access-Host-Port and
> Access-Method, Host-Name and Host-Port as well as Protocol. They are now
> all under URI (which is variant). Location has been modified to be
> Source-URI and Destination-URI and are variant.

Great.

> I have made some changes in the Email conventions as well. They are now
> to be specified as a Email URL, which is the same as a standard email
> address prefixed by "mailto:". 

I think that's a bad move -- it adds no functionality over the RFC-822
address, is more obscure, needs mailto: parsing capabilities in the
clients, and kills existing records (more difficult to fix in ALIWEB's
case as the records are all distributed over >1 admin domain). MIME/HTTP
uses the RFC-22 format. I strongly vote to revert this.
 
> > 2) 3.8.4
> >    [ ... ] Suggestions for this types include
> >    [ ... ] Other names may be constructed as necessary
> > 
> >    I think the draft should be a bit more specific if one is completely
> >    free to add new types oneself or if it is thought as "may be added in
> >    future releases of this document".
> > 
> 
> I have added the "future releases" language.

OK. I also suggest we explicitly mention that adding new fields is
allowed (although I still wouldn't mind requiring them to start
with X- to distinguish them from typo's, but I won't insist).

> However, we should make sure that we've covered all the bases here
> and that we haven't left any major object type out.

Difficult, but yes. You mentioned mailing lists, don't they fall under 
SERVICE? It needs Regstration etc.

> > If we dare and go one step on, I'd suggest a new cluster OBJECT which
> > would take fields like
> > Format: Size: Language: Character-Set: ISBN: ISSN: Protocol: Host-Name:
> > Host-Port: Pathname: Library-Catalog: Method: URI:
> > that really apply to a specific "object" that shares a same functionality
> > but maybe e.g. a binary for suns, decs, hps, sgi, or source code, or
> > as in the example it may be the same book in different encodings or
> > languages. But then all of the above fields may be different, while the
> > Author:, Admin, Description fields would be the same.
> 
> I agree that we should probably have a cluster for the more common
> elements that could be used in a number of different situations. However,
> I think in your examples above, you've cast your net a little wide (for
> example, very few things other than books are going to have ISBNs, by
> definition). Let's see if we can come up a with a small, standard set.

I agree, Object should probably not have IS?N.

> I have included below a diff between what I posted yesterday, and these
> new changes. This document is almost 1900 lines long, so I'm sure I have
> messed up somewhere in the changes... please tell me where :-)

Right. I have fixed some bugs, and appended a patch for them, against
draft-ietf-iiir-publishing-02.txt. 

Here are a few further points for discussion: (not in the patch)

An explicit mention on multiple fields is required (3.1?) : Are they allowed
(I suggest yes) or not? If so, what is are the semantics (I suggest
ordered multiple values). Something like:

	Duplicate data elements are allowed, and indicate alternative values.
	The order of the occurences indicates the order of preference.
	It is suggested, bu not required, to group multiple data elements 
	together to improve readability.

Do we need 'the companion document "Data Element Templates for
Internet Information Objects" [8]'? If so, it should probably be an
appendix. I suggest not though, the standard should be clear on it's
own; Iremoved it in the patch. Incidentally, I do intend to provide a
list of templates for ALIWEB users, but consider that an operational
issue. Would anyone like me to do it now, to check the final result?

In 3.4 scheme 2 disallows multiple records. Is that really required?
I can imagine needing one 'widgets' file in my widgets directory,
with records for related mailing lists, services, documents, and
people.

Do we want to make whitespace after the colon after a field name
optional? I suggest yes.

Re Short-Title, I suggest taking them out of the cluster, and add them
to any relevant templates (only DOCUMENT?).

I think 3.7.2 needs Host-Name as well as Host-Alias...

I think we need Pattern and Translation in 3.3 -- not all 
regexps are equal, and the translation isn't at all standard.

In 3.8.4, note 3: The name should be included where? I suggest
in the type; that way we can expand it to miltiple schemes:

	Library-Catalog-Dewy-v*:
	Library-Catalog-US-Congress-v*:

etc. (Excuse the examples :-)

That's it for now...

-- Martijn
__________
Internet: m.koster@nexor.co.uk
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster
Telephone: +44 115 9 520576
WWW: http://web.nexor.co.uk/mak/mak.html

*** draft-ietf-iiir-publishing-02.txt	Fri Aug 26 09:20:25 1994
--- draft-ietf-iiir-publishing-03.txt	Fri Aug 26 10:25:28 1994
***************
*** 99,105 ****
  Archives (IAFA) working group of the IETF. Special thanks are due to
  George Brett, Jill Foster, Jim Fullton, Joan Gargano, Rebecca Guenther,
  John Kunze, Clifford Lynch, Pete Percival, Paul Peters, Cecilia Preston,
! Peggy Seiden, Craig Summerhill, Chris Weider and Janet Vratney, Markus
  Stumpf and Martijn Koster.
  
  PREFACE
--- 99,105 ----
  Archives (IAFA) working group of the IETF. Special thanks are due to
  George Brett, Jill Foster, Jim Fullton, Joan Gargano, Rebecca Guenther,
  John Kunze, Clifford Lynch, Pete Percival, Paul Peters, Cecilia Preston,
! Peggy Seiden, Craig Summerhill, Chris Weider, Janet Vratney, Markus
  Stumpf and Martijn Koster.
  
  PREFACE
***************
*** 146,152 ****
  contacts, local time zone and other site-specific details may be given.
  
  Section 3 contains a set of encoding procedures for the information
! outlined in Section 2. These procedures allow the you, the AFA
  administrator, to take into account site-specific issues such as whether
  your particular operating system offers the capability of creating and
  using subdirectories, any limitations on filename length or the inability
--- 146,152 ----
  contacts, local time zone and other site-specific details may be given.
  
  Section 3 contains a set of encoding procedures for the information
! outlined in Section 2. These procedures allow you, the AFA
  administrator, to take into account site-specific issues such as whether
  your particular operating system offers the capability of creating and
  using subdirectories, any limitations on filename length or the inability
***************
*** 211,217 ****
     1.3 DIRECTORY SERVICES AND UNIFORM RESOURCE IDENTIFIERS
  
     Work is currently underway for the construction of what are known as
!    "Uniform Resource Identifiers". These will be structured strings
     whose purpose is to uniquely identify any resource on the Internet to
     determine access and identification information for that resource.
     This not only includes documents, software packages etc., but also
--- 211,217 ----
     1.3 DIRECTORY SERVICES AND UNIFORM RESOURCE IDENTIFIERS
  
     Work is currently underway for the construction of what are known as
!    "Uniform Resource Identifiers" (URI). These will be structured strings
     whose purpose is to uniquely identify any resource on the Internet to
     determine access and identification information for that resource.
     This not only includes documents, software packages etc., but also
***************
*** 285,291 ****
     to the complete organization or individual record and should be used
     preference to the complete entry. Indexing tools which gather template
     information should be aware that once removed from a particular
!    context, handles may no longer be unique and use technique to ensure
     unquieness in the expanded context.
  
     2.2 CLUSTERS: COMMON DATA ELEMENTS
--- 285,291 ----
     to the complete organization or individual record and should be used
     preference to the complete entry. Indexing tools which gather template
     information should be aware that once removed from a particular
!    context, handles may no longer be unique and use techniques to ensure
     unquieness in the expanded context.
  
     2.2 CLUSTERS: COMMON DATA ELEMENTS
***************
*** 315,321 ****
          - Name of individual.
  
  	- Name of organization to which individual belongs or under who's
!           authority this information is being made .
  
  	- Type of organization to which this individual belongs
  	  (University, commercial organization etc.)  
--- 315,321 ----
          - Name of individual.
  
  	- Name of organization to which individual belongs or under who's
!           authority this information is being made.
  
  	- Type of organization to which this individual belongs
  	  (University, commercial organization etc.)  
***************
*** 510,516 ****
  	  with corresponding contact information.
       
  
! 	This description would then indicate whether the the parent
  	organization offers such services as:
  
          o on-line library catalogues.
--- 510,516 ----
  	  with corresponding contact information.
       
  
! 	This description would then indicate whether the parent
  	organization offers such services as:
  
          o on-line library catalogues.
***************
*** 527,536 ****
  
          - Title of service.
  
!         - Short title of service.
  
- 	- URI of service
- 
  	- Contact information for service administration.
  
          - A description of the service.
--- 527,534 ----
  
          - Title of service.
  
! 	- URI of service.
  
  	- Contact information for service administration.
  
          - A description of the service.
***************
*** 824,830 ****
  
        Thus
  
!       12:00 GMT / 05:45 GMT
  
        is a valid time range. Multiple time ranges are separated by
        whitespace.
--- 822,828 ----
  
        Thus
  
!          12:00 GMT / 05:45 GMT
  
        is a valid time range. Multiple time ranges are separated by
        whitespace.
***************
*** 839,853 ****
        leading '+' and country and routing codes without separators.  The
        number should be given assuming someone calling internationally
        (without local access codes). The number given in the local
!       convention may optionally be specified.
  
        For example,
  
!       Telephone: +1 514 875 8189  (1-514-875-8611)
  
        or
  
!       Telephone: +44 71 732 8011
   
     10) Latitude and longitude are specified in that order as
  
--- 837,851 ----
        leading '+' and country and routing codes without separators.  The
        number should be given assuming someone calling internationally
        (without local access codes). The number given in the local
!       convention may optionally be specified in bracktes.
  
        For example,
  
!          Telephone: +1 514 875 8189  (1-514-875-8611)
  
        or
  
!          Telephone: +44 71 732 8011
   
     10) Latitude and longitude are specified in that order as
  
***************
*** 919,928 ****
  	  (first) column followed by a colon (:). All data element names
  	  must start in the first column.
  
!       (2) Field data must be separated from fieldname by whitespace. Any
! 	  field may continue on the next line by whitespace in the first
! 	  column of that line. Multi-line fields are delimited by the
! 	  first line which does not have whitespace in the first column.
  
        (3) Fields in the same record must not contain any blank lines
  	  between them.
--- 917,927 ----
  	  (first) column followed by a colon (:). All data element names
  	  must start in the first column.
  
!       (2) Field data must be separated from fieldname by a colon and
!           whitespace. Any field may continue on the next line by
!           whitespace in the first column of that line. Multi-line
!           fields are delimited by the first line which does not have
!           whitespace in the first column, or is blank.
  
        (3) Fields in the same record must not contain any blank lines
  	  between them.
***************
*** 948,958 ****
        (2) No indexing file under this scheme may contain more than one
  	  record (as defined above).
  
!       (3) Field data must be separated from fieldname by whitespace. Any
! 	  field may be continued on the next line by whitespace in the
! 	  first column of that line. Multi-line fields are delimited by
! 	  the first line which does not have whitespace in the first
! 	  column.
  
        (4) Fields must not contain any blank lines between them.
  
--- 947,957 ----
        (2) No indexing file under this scheme may contain more than one
  	  record (as defined above).
  
!       (3) Field data must be separated from fieldname by a colon and 
!           whitespace. Any field may be continued on the next line by 
!           whitespace in the first column of that line. Multi-line
!           fields are delimited by the first line which does not have 
!           whitespace in the first column, or is blank.
  
        (4) Fields must not contain any blank lines between them.
  
***************
*** 960,967 ****
     3.5 ENCODING
  
     Indexing files should be made world readable. It is assumed that size
!    and modification times can be obtained through the existing FTP
!    mechanism and are operating system specific.
  
     The advantages to this system are that this information need only be
     constructed once with infrequent periodic updates as changes occur.
--- 959,966 ----
     3.5 ENCODING
  
     Indexing files should be made world readable. It is assumed that size
!    and modification times can be obtained through existing access
!    mechanisms and are operating system specific.
  
     The advantages to this system are that this information need only be
     constructed once with infrequent periodic updates as changes occur.
***************
*** 1284,1290 ****
                                logical AFA.
  
  
!       Notes for this record.
  
  
        <1> The period is measured in days. This value should be chosen to
--- 1283,1289 ----
                                logical AFA.
  
  
!       Notes for this template.
  
  
        <1> The period is measured in days. This value should be chosen to
***************
*** 1303,1314 ****
  			    contained in this archive is in the
  			    public domain
        Admin-Name:	    Ima Admin
!       Admin-Email:	    mailto:imaa@oxymoron.com.uk
        Admin-Work-Phone:     +44 71 123 4567
        Admin-Work-Fax:	    +44 71 123 5678
        Admin-Postal:	    555 Marsden Road, London, SE15 4EE
        Record-Last-Modified-Name: Yuri Tolstoy
!       Record-Last-Modified-Email: mailto:yt@snafu.com.uk
        Record-Last-Modified-Date:	Mon, Jun 21 93 17:03:23 EDT
        Update-Frequency:     20
        Keywords:	    	    Militarism, Post Office, Conservatism
--- 1302,1313 ----
  			    contained in this archive is in the
  			    public domain
        Admin-Name:	    Ima Admin
!       Admin-Email:	    mailto:imaa@oxymoron-x.co.uk
        Admin-Work-Phone:     +44 71 123 4567
        Admin-Work-Fax:	    +44 71 123 5678
        Admin-Postal:	    555 Marsden Road, London, SE15 4EE
        Record-Last-Modified-Name: Yuri Tolstoy
!       Record-Last-Modified-Email: mailto:yt@snafu.co.uk
        Record-Last-Modified-Date:	Mon, Jun 21 93 17:03:23 EDT
        Update-Frequency:     20
        Keywords:	    	    Militarism, Post Office, Conservatism
***************
*** 1388,1395 ****
  				      will be updated/fetched.
  
        Update-Exclude-Pattern:	      A regular expression. Files matching this
! 				      pattern on Source-URI will not
! 				      be updated/fetched.
  
        Update-Compression-Pattern:     A regular expression. Used for packing
                                        or re-packing files being updated/
--- 1387,1394 ----
  				      will be updated/fetched.
  
        Update-Exclude-Pattern:	      A regular expression. Files matching this
! 				      pattern on Source-URI will not be
! 				      updated/fetched.
  
        Update-Compression-Pattern:     A regular expression. Used for packing
                                        or re-packing files being updated/
***************
*** 1399,1404 ****
--- 1398,1404 ----
  				      for the automatic updates.
  
  
+       Notes for this template:
  
        <1> The -v* form is especially useful, if you mirror a package within a
  	  directory called "path", but you don't mirror the whole "path", but
***************
*** 1405,1411 ****
  	  only the "src" and "doc" subdirectories.
  
        <2> This may be any number or one or more of the (comma seperated) words
! 	  "Mon", "Tue", Wed", "Thu", "Fri", "Sat" or "Sun"
  
        <3> Valid keywords are:
              autodelete  - files will be automatically deleted, when they are
--- 1405,1411 ----
  	  only the "src" and "doc" subdirectories.
  
        <2> This may be any number or one or more of the (comma seperated) words
! 	  "Mon", "Tue", Wed", "Thu", "Fri", "Sat" or "Sun".
  
        <3> Valid keywords are:
              autodelete  - files will be automatically deleted, when they are
***************
*** 1431,1437 ****
        Example:
        --------
  
!       This is an example of a AFA-MIRROR file.
  
        Template-Type:			MIRROR
        Admin-Name:			John Long Silver
--- 1431,1437 ----
        Example:
        --------
  
!       This is an example of a MIRROR record.
  
        Template-Type:			MIRROR
        Admin-Name:			John Long Silver
***************
*** 1476,1482 ****
  
        To allow for the use of "handles" and so as not to require the
        repetition of the USER* information each time this cluster is
!       needed in other templates we define here a USER template in which
        the information can be stored in one place. Assuming the use of a
        unique handle, other records may then refer to this template to
        complete the require information. The definition is simply the data
--- 1476,1482 ----
  
        To allow for the use of "handles" and so as not to require the
        repetition of the USER* information each time this cluster is
!       needed in other templates, we define here a USER template in which
        the information can be stored in one place. Assuming the use of a
        unique handle, other records may then refer to this template to
        complete the require information. The definition is simply the data
***************
*** 1539,1545 ****
                          general access is not available.
  
  	Charging-Policy:
! 			Free text field describing any changing
  			mechanism in place. Additionally, fee structure
  			may be included in this field.
  
--- 1539,1545 ----
                          general access is not available.
  
  	Charging-Policy:
! 			Free text field describing any charging
  			mechanism in place. Additionally, fee structure
  			may be included in this field.
  
***************
*** 1570,1577 ****
                          verified.
  
  
! 
!       Notes on this file.
  
        <1> The Internet protocol used to communicate with this service.
        	  For example, "telnet" or "SMTP" or "NNTP" etc. A more complete
--- 1570,1576 ----
                          verified.
  
  
!       Notes for this template.
  
        <1> The Internet protocol used to communicate with this service.
        	  For example, "telnet" or "SMTP" or "NNTP" etc. A more complete
***************
*** 1629,1641 ****
        3.8.4 DOCUMENTS, DATASETS, MAILING LIST ARCHIVES, USENET ARCHIVES,
  	    SOFTWARE PACKAGES, IMAGES AND OTHER OBJECTS
  
!       This file contains records with the following fields.
  
-       For multi-record files each record is started and the previous
-       record is delimited by the "Template-Type" field which also
-       determines the type of object being indexed. Suggestions for these
-       types include:
- 
        Type of Object			Template-Type
        -------------- 	        	--------------
  
--- 1628,1636 ----
        3.8.4 DOCUMENTS, DATASETS, MAILING LIST ARCHIVES, USENET ARCHIVES,
  	    SOFTWARE PACKAGES, IMAGES AND OTHER OBJECTS
  
!       These templates all contain the same fields, but have different
!       "Template-Type" values. Suggestions for these types include:
  
        Type of Object			Template-Type
        -------------- 	        	--------------
  
***************
*** 1725,1731 ****
  
  	Size-v*:		Length of object in bytes (octets).
  
- 
  	Language-v*:		The name of the language in which the
  				object is written. For documents this
  				would be the natural language. For
--- 1720,1725 ----
***************
*** 1745,1751 ****
  	URI-v*:			Description of access to object. This is
  				not required if naming scheme 2 is used.
  	
- 
          Last-Revision-Date-v*:  Last date that the object was revised.
  
  
--- 1739,1744 ----
***************
*** 1776,1783 ****
        ---------
  	  
  
!       Example of AFA-OBJECT file for the DOCUMENT type. Note that this
!       example contains variant information.
  
        Template-Type:		DOCUMENT
        Title:			The Function of Homeoboxes in Yeast
--- 1769,1775 ----
        ---------
  	  
  
!       Example of DOCUMENT record.
  
        Template-Type:		DOCUMENT
        Title:			The Function of Homeoboxes in Yeast
***************
*** 1820,1829 ****
        Example 2
        ---------
  
!       This is an example of a software entry. Note the use of the
        software maintainer's "handle" instead of the explicit contact
!       information. This could be used if there was a well-known external
!       method of resolving this handle.
  
        Template-Type:	SOFTWARE
        Title:		Beethoven's Fifth Player 
--- 1812,1820 ----
        Example 2
        ---------
  
!       This is an example of a SOFTWARE record. Note the use of the
        software maintainer's "handle" instead of the explicit contact
!       information.
  
        Template-Type:	SOFTWARE
        Title:		Beethoven's Fifth Player