Re: New feature tag registration drafts available

Graham Klyne:
>
> 
>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.


Graham,

Thanks for your quick comments.  All the other ongoing HTTP issues
prevent me from responding to these comments just as quickly, but here
is a first batch of responses.

>
>I don't know how long you have been brewing your ideas in this area,

Actually, I thought up most of it over last weekend, though I have been
thinking longer about some parts.  I think the scenarios draft in
particular is still a bit rough in some areas, and I intend to make
another pass over it before the Munich ID cutoff.

> but
>they are very close in concept to one aspect of the protocol-independent
>negotiation framework that I have recently been suggesting.

Yes, that was the idea.  Note however that the drafts strictly limit
themselves to providing a namespace only, they do not define other
mechanisms which could be commonly used, even though the existence of
such mechanisms is conceivable.  

To make rapid progress on getting at least the namespace in place, I
limited the drafts to the namespace only.

> 
> * 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.

Yes, you often have negotiation in which dimensions are
interdependent, and the drafts do not exclude such cases (at least I
did not mean them to).

>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'.

I like to think of the namespace as unstructured: there is no
predefined order in which negotiation on features has to be done.  I
think that any ordering in the namespace would exclude some legitimate
use cases in which the order would have to be just the other way
around.  My idea is to leave ordering (and in general the question of
how to handle the presence or absence of interdependency between
dimensions in any particular negotiation case) outside of the scope of
the registry.

Another thing which would be outside of the scope of the registry is
the distinction between the two cases `if the other party does not
understand the meaning of this tag, it is safe to proceed with
negotiation' and `if the other party does not understand the meaning
of this tag, it is *unsafe* to proceed with negotiation'.  Again, I
think that there are tags for which either one could be true depending
on the specific negotiation case.  So this distinction would have to
be conveyed with metadata, which is attached to the tag when it is
transmitted, rather than being encoded in its registration entry.  The
metadata format could either be general or bound to a specific
negotiation mechanism.

I plan to make such in/out of scope distinctions more explicit in a
revision of the scenario draft.

[...]
>* Section 4.2:
> 
>(a) I note that you are still adopting a very web-centric view in
>notionally application-independent draft.

I intended 4.2 be read as an example, not as an exhaustive list.  I
see I did not make that very clear in the title, though.

More later...

>GK.

Koen.

Received on Thursday, 10 July 1997 14:09:19 UTC