Re: New feature tag registration drafts available

At 10:43 PM 7/7/97 +0200, Koen Holtman wrote:
>
>I have made two new drafts about feature tag registration 
>[...]
>
> draft-ietf-http-feature-scenarios-00.txt 
>     `Feature Tag Scenarios' 
>     Discusses why we need feature tag registration.

Koen,

Following a first read-through the feature secanarios draft, I have some
comments for you.

I don't know how long you have been brewing your ideas in this area, but
they are very close in concept to one aspect of the protcol-independent
negotiation framework that I have recently been suggesting.


* Section 2.1:

I like your characterization of the problem as a multidimensional search
process.  But, following a discussion I had the other day, I wonder if this
may be insufficient.

The specific scenario was that of a device which contains a small LCD
display and a printer.  Such a device could reasonably be used for WWW
browsing, using the small display to display menu choices and the printer
to display content.

One way to support this would be for content negotiation to say "Accept:
(<low-resolution> AND <refreshable-display> AND <contains-hyperlinks>) OR
(<high-resolution> AND <hardcopy> AND <no-hyperlinks>)".  This requires
that the various feature dimensions (as they have been portrayed in various
discussions to date) are not necessarily negotiated independently of each
other.

One approach I can conceive is to allow a feature-set to be used as a
feature for negotiation purposes, thus creating a recursively structured
feature-set space.  Allowing this allows the above scenario to fit within
the negotiation model you suggest if you allow compound 'dimensions'.


* Section 2.2, final para:

I noted two points here which, in due course, might be drawn out as
explicit requirements:

(a) "should not be bound to a particular protocol or negotiation mechanism"

(b) "should be no prior restriction on the things which can be identified
by a feature tag"


* Section 3.1:

A nit-pick...

I agree with the point you are making but I question the example you choose.

I understand HTTP negotiation to be extensible, in that server-side
negotiation can depend upon *any* of the supplied request headers,
including extension headers.  See the description of "Vary", section 14.43,
first paragraph and final paragraph; also section 12.1, last-but-2 paragraph.


* Section 3.2 para 1:

In stead => Instead.


* Section 3.2, para 3:

I found the term "central database" was a little confusing.  It was not
immediately clear that this referred to data stored within the browser, as
opposed to some external directory.  How about "common internal database"?


* Section 4.2:

(a) I note that you are still adopting a very web-centric view in
notionally application-independent draft.

(b) Within a web context, I would offer some additional possible parties
who might wish to register feature tags:

- Server vendors (incl. proxy/gateway vendors)

- Hardware vendors

- Vendors of software used by CGI scripts or other server software plug-ins

- Vendors of client plug-in software

- Other third party software vendors (e.g. networked information providers
which might be invoked by gateway servers providing access to specialized
information).


* Section 4.3, item t+2.5:

This implies another requirement:  it must be possible for content authors
to specify feature tags and associated values in authored content (this has
possible implications for representability within HTML, for example).


* Section 4.4, para 2:

I think there is a potential problem more pernicious than 'dead' tags,
etc., which is use of different tags by different vendors to mean the same
thing.  This could cause unecessary negotiation failures -- maybe some
alias mecchanism could be defined within the registration procedures?


GK.
---

------------
Graham Klyne
GK@ACM.ORG

Received on Thursday, 10 July 1997 08:34:19 UTC