At 11:05 PM 7/10/97 +0200, Koen Holtman wrote:
[...]
>To make rapid progress on getting at least the namespace in place, I
>limited the drafts to the namespace only.
Fine. (And I like the hierarchical namespace approach.)
>> * 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.
>
>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).
OK. (I think it's the term 'dimension' -- it tends to imply a scalar
associated value.)
>I like to think of the namespace as unstructured: there is no
>predefined order in which negotiation on features has to be done.
Another draft to cover a generic negotiation framework? (Not to specify an
order, but partly to make it clear that there is no predefined order.)
>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.
Hmmm... I'm not sure one could construct a sufficiently general metadata
fraework either. I had assumed that such detail would be bound up in the
semantics of a particular tag: e.g. any component which new about a tag
would know what kind of response (if any) would be needed to conclude
negotiation w.r.t. that tag.
>I plan to make such in/out of scope distinctions more explicit in a
>revision of the scenario draft.
I think it was fairly clear that details of values associated with the tags
were not part of the feature tag. But I felt there were implicit
assumptions about the range and complexity of values which might be allowed.
>[...]
>>* 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.
That comment of mine was slightly tongue-in-cheek. And I just wanted to
raise a flag concerning the possibility of Web-centric thinking allowing
assumptions to creep in.
It was clear from what you wrote that it was just an example.
GK.
---
------------
Graham Klyne
GK@ACM.ORG