Re: Draft progression

[Alan Emtage <[e-mail]>]

Hi Martijn,

> Alan, have you had a change to look the comments I mailed to the list
> a while back?

Funny you should say that :-) I've been working on the draft (off and on)
for the past couple of days and compiling comments (and comments to the
comments). Here they are, along with a new version of the draft. I have
incorporated most of your changes, cleaned up some of the text for
clarification and added a few new fields. I won't worry about commenting
on the typos etc....

BTW, I have taken the liberty of adding Markus' and your name to the
masthead. You guys have certainly done enough work on this document for
you to be up there too :-)

Here goes:


>From [e-mail] Thu Jun 30 11:51:41 1994
To: [e-mail], [e-mail] (Alan Emtage)
Subject: Comments on draft-ietf-iiir-publishing-01.txt
Date: Thu, 30 Jun 1994 15:20:35 +0100
From: Martijn Koster <[e-mail]>

> BTW, is the iafa list still the place to discuss this now the draft fits
> under the iiir umbrella?

At this late date, lets just keep it under the iafa mailing list
(although the group is officially disbanded). The IETF process however
will be conducted through the IIIR.

> 1.3.1, last paragraph:
> 
> > It is hoped and expected that the methods of information
> > dissemination described in this document will be superseded by a
> > more comprehensive system in the relatively near future.
> 
> What exactly is meant here?

It is just a side comment saying in effect that this is not really the
way to go in indexing the net, but it's the best that we can come up with
at the moment so let's do something at least (says the person who has
taken 2 years on this document :-)


> 3.3, point 3:
> 
> > All host IP addresses are given in "dotted-quad" (or
> >      "dotted-decimal") notation. 
> 
> These aren't explicitly entioned elsewhere, all hostnames are in FQDN.

True, however it is sometimes necessary to use IP addresses (and I
certainly didn't want to _disallow_ them) so I decided to make the format
clear.

> 
> > date-time   =  [ day "," ] date time 
> 
> time should be optional, see eg 3.8.4, Example 1, Last-Revision-Date.

Correct. 


> 3.3, point 9:
> 
> This specifies telephone numbers without the standard leading '+'
> which is used in all the examples. I suggest the definition is
> ammended to include the '+'.

Correct.

> 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
> User-(ORGANIZATION*).

Actually I think the confusion here is that I said that it was the
organization "to which the user or group belongs". I've removed that last
part of the sentence. There are cases in which the organization
responsible for the particular record need not be asssociated with a
group or individual.


> >      The following is a list of generic data element subcomponents used
> >      when referring to particular resources.
> 
> It is unclear where these fit in. Can all templates have these? If so why
> are things like "Description" and "Keywords" explicitly listed for
> some other templates?

They are there more for emphasis than anything else. There were templates
which I thought would be particularly useful if they had these elements
and so I specifically put them in there.

> What is the relationship between Title, Short-Title, and things like
> Name in normal templates?  Are Title and Short-Title recommended for
> all templates, if not what point is really served by them being there?

Good point. I have changed the "Name" field in the SERVICES template to
be "Title". I believe that "Title" is a more generic term for the concept
we're trying to capture here.... however it's really six of one and half
dozen of the other. I've tried to standardize on "Title" and see if that
flies....


> Suggest "Alias" is renamed "Host-Alias" to indicate what the alias is for.

Done.

> ---
> 
> 3.7.1, footnote <1>
> 
> The format for the Lat-Long should probably be in 3.3 Data Formats

Done.

> ---
> 
> 3.7.1, example
> 
> Examples uses Name where the template specifies Host-Name. Suggest 
> the example is fixed.

Done.

> -- 3.7.2
> 
> Where is Last-Modified-Date ? Suggest it is added.
> 
> The formatting of the description list is inconsistent.

Done.

> The definition for *-Location-v* mentions a URL for the first time,
> without definition or reference. I suggest these become "URI", or
> preferrable, the entire document uses URL's.

Hmmm...I actually prefer "URI", the reason being that URI is supposed to
be the "generic" term for URLs, URNs and (one day) URCs. The syntax of
the particular UR* is supposed to be syntactically determinable from its
form, so we can leave it as it is. In addition URNs should be mappable to
URLs (that's the intention at least), so we can remain ambiguous at this
point.


> The URI's in *Location-v* have "URL:<url>". I know this is the current
> thinking for URI's, but what's wrong with just the URL, as a _location_
> is being described?

Guess this is a moot point now. The URI group removed the leading "URL:"
syntax at the last meeting in Toronto.

> 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).
> 
> My understanding is that in a multi-record IAFA file (e.g. and ALIWEB
> index file) you can use a USER template with a handle, and then further
> references to that record from other records in the file. In that case
> no Directory service is required, as all information is available. 
> I suggest this scenario should be explicitly mentioned.
> 
> If you do want to use Directory services you're in a different
> ballgame.  What can you fill in, if you don't know what directory
> service is to be used, and what can automated index collectors do with
> it if they don't know what directory to use to resolve it? You're
> definately going to need a global White Pages URL here, and that won't
> exist for a while.
> 
> There should be an indication of uniqueness, are Handles supposed to be
> unique withing a multi-record document, a site, or world-wide.

Well put. I've been worried about this aspect myself since, as you said,
its very difficult to see a Global WP service anywhere in our near
future. I'd be happy at this point to restrict handles to being shorthand
internally, however there is a problem with this. Once the record is
removed from its (local) context into an indexing system (such as
ALIWEB), how does one guarantee uniqueness any longer (even though the
handle may have been unique in the local context) ? I guess the only way
to do this would be to have the indexing system try to "uniquify" the
handle before entering it into a global index.

I have added wording to this effect in section 2.1. Comments welcomed.

> ---
> 
> 3.8.2
> 
> > In a similar manner to the USER template, the ORGANIZATION template
> >  provides common information which may be used in other (larger)
> >  templates to yielding a central source of information.
> 
> "yielding" should be "yield"
> 
> ---
> 
> 3.8.3
> 
> Why serviceS when everything else is singular?

Good question. My guess is that its too late to change it now :-( I'll
leave it a as is.

> Example 2:
> 
> > Address: [e-mail]
> 
> Address is not defined, and "[e-mail]" probably has little
> to do with fishlovers anyway?

True on the last point. 

As to the use of "Address:", it probably should have a more structured
name, but the use of the term itself is not "illegal" since the document
also says that the record creator has the ability to add arbitrary data
elements as need. Should there be an additional record type to describe
mailing lists since this is one of the most common services? I'm not sure.


> 3.8.4
> 
> Author-(USER*), Admin-(USER*) "may be repeated as often as necesarry"
> 
> Hmmm... Why are these for multiple people here, and not anywhere else?
> How can we parse this, when you don't know where one person begins
> and another ends, e.g.
> 
>
>    Author-Name: Martijn Koster
>    Author-Email: [e-mail]
> 
> When parsing IAFA templates, what should one do with duplicate fields
> normally? I consider them an error.

Duplicate fields are not necessarily an error. However, I have added
language to the CLUSTER definition to explain that "variant record"
syntax should be used for repeated fields.

> ---
> 
> 3.8.4
> 
> > Format-v*
> 
> Sounds like MIME types could be used here.
> 
> In the example Author-Home-Phone has an illegal semicolon.
> 
> In the example 1, Last-revision-date has an illegal date,
> the month is too long and the time is missing (see also date-time
> discussion above)
> 
> ---
> 
> General formatting: some lines end in a period, others don't, even in
> the same sections. Some of the lines wrap on standard vt100 screens.
> Sometimes sentences are separated by double spaces, sometimes by
> single ones.  Sometimes footnotes are referred to by "See Note <1>",
> sometimes in brackets, sometimes by <1>. "etc." has't always got the
> dot.

I've tried to clean some of that up, but anything that you can see in the
current draft to be released in a couple of minutes, please send them in.


-- 
-Alan

------------------------------------------------------------------------------
Alan Emtage,				"The Left in Canada is more gauche
Bunyip Information Systems,		 than sinister"
Montreal, CANADA			 -The Economist

[e-mail]
Voice: [phone]		Fax: [phone]