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
- Re: Draft progression Alan Emtage
- Re: Draft progression Alan Emtage
- Re: Draft progression Markus Stumpf
- Re: Draft progression Alan Emtage
- Re: Draft progression Martijn Koster
- Re: Draft progression Markus Stumpf
- Re: Draft progression Martijn Koster
- Re: Draft progression Alan Emtage
- Re: Draft progression Markus Stumpf