Area Director hat on...
I've been reading the comments on this issue with considerable interest. At
this point I think it is important to point out that at least two entirely
issues are being conflated here. Specifically, splitting something into two
documents doesn't mean that the two documents comprise separate specifiations.
Nor, for that matter, does having a single document mean that there wouldn't or
couldn't be two conformance levels to AS2.
There are plenty of examples of specifications split into multiple documents in
the IETF. MIME, for example, is split into 5 documents, RFCs 2045-2049. I'm not
aware of any case where this has caused problems: You frequently hear people
refer to "MIME conformance", but not "RFC 2045 conformance".
SNMP is an even better example. Here we have multiple specification versions,
each split up into who knows how many base documents. Yet again, I've never
heard of there being a problem with peoeple claiming selective conformace to a
specific documents within an SMNP version. (Conformance to different SNMP
versions is another matter, but we really don't want to go there...)
When I hear claims that there's a problem of clarity in the single document --
a claim I don't think has been contested -- I start to think that splitting
things into multiple documents is worth considering. I therefore suggest that
this issue be dealt with indepenently of what it means to conform to AS2. If
splitting the material into two documents makes it clearer it is something that
should be done. If not, it shouldn't.
In regards to specification conformance and assuming AS2 is split into two
documents, there are all sorts of ways this could be handled:
(1) (MIME approach) Everybody has to support both documents in order to claim
conformance to AS2.
(2) (PL/I approach) You can support what you want and claim conformance to
AS2(1) or AS2(2), but you cannot claim to conform to AS2 without
supporting both.
(3) (PostScript approach) There's no such thing as conformance to AS2 as a
whole, you implement and claim conformance to either part independently.
(4) The issue is left to other groups to address.
Of these the only one I'd have issues with is (4). The goal of IETF
specifications is interoperability. And one of the tools that's been effective
in achieving interoperability has been conformance criteria. Therefore the
decision to abandon this tool should not be taken lightly.
I'm well aware, however, that this is a case where various other groups will
likely profile anything the IETF produces. So what the IETF says constitutes
conformance may not end up being what matters to vendors. But that's not an
excuse for not doing our jobs.
In any case, I do think that the two issues should be dealt with independently
and the document structure issue needs to be addressed first. If nothing else,
it would help to make it clear to everyone what's in each part.
Ned
P.S. I've used the term "conformance" rather than "compliance" throughout this
message. This was an intentional choice: To me, compliance tends to imply
measurement or testing will be done to insure things work as intended. But this
is not something the IETF does, at least not directly.
|
