Re: Comments on draft-ietf-iiir-publishing-01.txt

Martijn Koster <> Mon, 11 July 1994 18:00 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa06956; 11 Jul 94 14:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06952; 11 Jul 94 14:00 EDT
Received: from by CNRI.Reston.VA.US id aa16459; 11 Jul 94 14:00 EDT
Received: by (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05171 on Mon, 11 Jul 94 13:08:03 -0400
Received: from sifon.CC.McGill.CA by with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05161 (mail destined for /usr/lib/sendmail -odq -oi -fiafa-request iafa-out) on Mon, 11 Jul 94 13:07:41 -0400
Received: from ([]) by sifon.CC.McGill.CA (8.6.8/8.6.6) with ESMTP id NAA01348 for <>; Mon, 11 Jul 1994 13:07:09 -0400
Message-Id: <199407111707.NAA01348@sifon.CC.McGill.CA>
Received: from (actually by with SMTP (PP); Mon, 11 Jul 1994 18:06:44 +0100
To: Markus Stumpf <>
Cc:, "m.koster" <>, bajan <>, maex <>
Subject: Re: Comments on draft-ietf-iiir-publishing-01.txt
In-Reply-To: Your message of "Sat, 09 Jul 1994 21:03:58 +0200." <2vmoqe$>
Date: Mon, 11 Jul 1994 18:06:30 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Martijn Koster <>

Markus, as I haven't had a reply to my question if this list is still
the appropriate form for discussion of this -iiir- draft I asked the
iiir chair, but haven't heard from him either... :-/

In reply to your comments:

> >3.6.1
> >It seems to me that Organization-Name and Organization-Type do not fit
> >into the template very well, where are the other ORGANIZATION*
> >elements, especially Handle? I suggest explicitly mentioning
> >ORGANIZATION* elements can be part of USER*, or adding an element
> I second that. If there shall be some organizational attachment to
> a USER cluster we should have the full ORGANIZATION* elements.
> Thus I'd also suggest to exchange 3.6.1 and 3.6.2
> However, why is 3.6.1 named "INDIVIDUALS AND *GROUPS*" ??
> I can't the GROUPS fit very well into the USER cluster. And if we
> don't assume a organization to be commercial (as I do usually ;) )
> I think they'll better fit with the ORGANIZATION cluster and the
> sections should be
> ---

> I think this section may be completely deleted.
> There is no relevant information that is not repeated later on in the
> exact template definitions and may lead INHO to confusion.

Agreed, although it may make sense to explicitly list suggested
attributes that can be added to any current and future record, such as
Last-Modified-*, Last-Verified-* etc.

> I think Shot-Title is unnecessary, als we have Title and Description
> and so Title could be used for short infos and Description for longer ones.
> BUT: Title mainly applies to the DOCUMENT type. All other types would
> better do with a Name tag. This tag is also used with all but the OBJECT
> types. I don't kniw whether it would be valid in good english to speak of
> the name of a document instead of the title (in Germany it would ;)) )
> but if, I'd like to see the use of Name instead of Title in all templates.
> This would make it also simpler to parse.

Yes, I've been wanting a single naming attribute for ages too.; but it have
almost given up on that.

> 3.8.1, 2.1 and other places
> >I feel a bit unhappy about the use of handles without giving any indication
> >of how they are to be used other than :
> >> NOTE: A handle should be used in preference to a fully expanded entry
> >>  in those situations where a handle for an individual, group or
> >>  organization can be obtained and subsequently resolved by some other
> >>  (external) method (directory service).
> >There should be an indication of uniqueness, are Handles supposed to be
> >unique withing a multi-record document, a site, or world-wide.
> Would there any problem allowing URIs (or URLs) as handles?
> Thus I could simply use
> Author-Handle:
> and on this page you'll probably find (or at least should find) all the
> information that usually is in the USER* cluster. Most of the organizations,
> groups or individuals I've checked have such "HOME pages", so it will
> be a good start.
> Allowing URIs for Handles is IMHO also a good start as it is flexible
> and may be changed to a URI poiting to some kind of directory service
> some time in the future.

But the records may be used off-line, and then you're in trouble.
I think having URI as a PERSON attribute gives you that functionality
while still allowing other info to be carried in-place. But we do need
something to matchup those handles.

> 3.8.4
> [re ordering of attributes]
> Alan Emtage wrote:
> ae> Now we have a potential problem. Which home phone number belongs to which
> ae> Author? My only solution is to put an ordering.
> ae> [...] For the "clusters" we define that the -Name fiel> d 
> ae> must be first within the cluster to disambiguate the above.
> Think this is a good and workable solution. Same as Template-Type has
> to be the first in a template file *-Name: should have to be the first
> in a USER* cluster. Same should apply to ORGANIZATION* as well.

Fine, but it needs to explicitly stated in the standard. And this
requires the identification of a naming field (as not everything has
-Name) Of course an alternative (an easier to parse) solution is use a
numbering scheme ala -v*

 Template-Type: SOUND
 Title: Southern Cross
 Author1-Home-Phone: +1 800 555 1212
 Author1: Crosby
 Author2: Stills
 Author2-Home-Phone: +1 415 234 5678
 Author3: Nash

> And here a few comments I haven't seen in Martijn's mail.
> For all this services and especially for the user it is of big help
> to have all the relevant information for a object available for
> cut 'n paste.

Yes. One of the things I want to do for ALIWEB after the RFC is out is
create a set of HTML forms to maintain your index file (as suggested at
www'94). Maybe a list of templates should be added as an appendix?

> Currently we only have Access-Protocol, Access-Host-Name, Access-Host-Port
> and Pathname. (I wonder why Pathname has no Access- prefix?).
> The example also has a Access-Method which is not listed in the definition.


> Why can't we define another cluster called OBJECT and have it:
> Format:
> Size:
> Language:
> Character-Set:
> Protocol:
> Host-Name:
> Host-Port:
> Pathname:
> Library-Catalog:
> Method:
> URI:
> One would then have three choices:
> 1) URI:		for easy access and cut 'n paste
> 2) Method:	a textual description
> 3) Protocol, Host-Name, Host-Port, Pathname:	for better known
> 		access methods that don't have assigned a URL type yet.
> in the AFA-OBJECT then have a 
> 	Access-(OBJECT*)-v*:
> or even simpler a
> 	(OBJECT*)-v*:
> Same applies to the SERVICE type, too.

I feel OBJECT is a bit too general; for example an ISBN isn't going to
be available for most network-based objects. But in general, where
similar sets of attributes are used a cluster would be nice (role on
X.500 oidtables :) The reason I'm not too pushy on that is that I
don't want to corrections to the draft to become so extensive it will
be kicked back by the RFC edittor.

> 3.8.4
> > [ ... ] Suggestions for this types include
> >
> > [ ... ]
> >
> > Other names may be constructed as necessary.
> How do I have to read this?
> Am I free to e.g. create a new type FONT, pick up some data elements that
> would fit from section 3.8.4 and voila we have a new Template-Type ??

That's how I read it, and it sounds reasonable.


What I want to know is, where are all those people? The only input on
this list seems to come from three people :-(

-- Martijn
X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M
X-500: c=GB@o=NEXOR Ltd@cn=Martijn Koster