W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 2004

Remaining issues with the bind draft -- process

From: Patrik Fältström <paf@cisco.com>
Date: Mon, 5 Apr 2004 20:55:37 +0200
Message-Id: <D3828D62-8732-11D8-AB6C-000A95B2B926@cisco.com>
To: Webdav WG <w3c-dist-auth@w3c.org>

Julian 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?

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

Received on Monday, 5 April 2004 14:56:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:31 UTC