Re: Remaining issues with the bind draft -- process

Patrik Fältström wrote:

>> Lisa Dusseault wrote:
>>
>>> I've re-reviewed the bind draft. Many of these issues have come up
>>> before but I feel they haven't been resolved in the draft.
>>>
>>> General
>>> -----------
>>>
>>> The spec must stand alone, not be dependent on changes to RFC2518 in
>>> 'bis'. Otherwise, bind can't be approved until RFC2518bis is approved.
>>> That means no dependencies for things like 'lockroot'.
>>
>>
>> There isn't any.
> 
> 
> Lisa, was your reference to 'lockroot' a pointer to one such reference 
> which exists, or something which is added to 2518bis which you point out 
> is not allowed to be used in the bind draft?

Lisa was probably referring to a previous discussion where we agreed 
that clients will *benefit* from the new DAV:lockroot element, because 
it allows them to programatically discover which URL is protected by a 
lock. However, this is a nice-to-have feature, and clients certainly 
don't require it (after all, they should know the URL because they 
usually issued the LOCK request themselves). So the consensus (imho) was 
that it's presence in RFC2518bis simply is "good enough".

If people feel that DAV:lockroot only being defined by RFC2518bis 
actually is a problem, we can add it to BIND. However, I'd like to avoid 
it because it creates an area of overlap that doesn't seem to be necessary.

>>> In general, the spec needs more info to specify how existing things
>>> work. All the following questions must be answered in the spec, NOT just
>>> in email. The spec must be explicit, because different people reading a
>>> model description always end up with different ideas how the model works
>>> in practice.
>>
>>
>> Here I disagree.
> 
> 
> Remember I asked a question explicitly about interoperability between 
> things developed by just reading the spec...then look at the list below. 
> I don't see the statement "yes, there will be interoperability" matches 
> those statements.
> 
> Can you explain?
> 
>> First of all, there are several ways to resolve questions raised:
>>
>> 1) If there is a simple answer based on existing specs and the current
>> draft, just answer it here on the mailing list.
>>
>> 2) If the issue is likely to be re-raised (because the answer is not
>> obvious), record it (and the answer) on the issues list.
>>
>> 3) If the issue is indeed valid, add it to the issues list and attempt
>> to resolve it.
>>
>> In general, there are areas where the spec *can't* specify how existing
>> things work, because they depend on specific implementations. I
>> absolutely agree that those situations should be avoided, but sometime
>> there's nothing we can do about that.
>>
>> I'll post answers to the specific issues in a separate mail.

Patrik, I'm not sure what you're asking for. There'll always be the 
possibility that people misunderstand a spec, don't read a normative 
reference, or just miss something.

So the question about expected interoperability leads nowhere unless 
it's a *specific* spec question - of course the authors expect that the 
spec is sufficient for interoperable implementations, otherwise we 
wouldn't ask for last-call.

And of course it's possible (or actually likely) that we missed 
something. That's why we're asking for feedback; and the most efficient 
way to get feedback is by last-calling the document in the working group 
(the fact that we're having this discussion sort of proves it, right?). 
So as long as we're getting *new* questions, it's fine to delay the 
last-call; however once the mail threads stop (which they did last 
week), we should move on.

Best regards,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Monday, 5 April 2004 15:39:35 UTC