RE: Split within EDIINT: Multiple versions of AS2

All,

Since throwing in my own comments a few days ago, I have been watching
developments with interest.

So far, it would seem that the split is fairly even between those advocating
the splitting and those for keeping the merge but Ned now raises some
interesting points.

From my own point of view, I don't see that creating two documents really
solve the clarity issue when a single document can be restructured to
achieve the same effect. Personally, I found the splitting of the MIME
specification over multiple documents to be a real pain when we first
started doing some work in this area. 

I've been out of the deep technical loop on this for some time so please
don't shoot me if I get some things a little bit wrong...

The original split between AS1 and AS2 was purely due to the difference in
delivery mechanism - one used SMTP/POP3 and the other HTTP. Could it not be
said that this is still true today and in fact both the 'UCC' and 'Energy'
variants could be carried by either mechanism? Actually, if this is not true
then maybe it should be.

This would therefore suggest that it may be time to take a step back from
AS2 and re-think the definition of EDIINT as a whole.

It would seem to me that a possible rework of the specifications would be...

  Doc 1 - Delivery mechanisms (SMTP/POP3 and HTTP)
  Doc 2 - Enveloping (S/MIME and PGP)

There is a lot I could say on the matter but I think I'll leave it there for
initial comments.

Regards
Andrew Stickland
Manager, Technical Services
mailto:[email protected]



-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: 20 January 2003 16:38
To: [email protected]; [email protected]; [email protected]
Subject: RE: Split within EDIINT: Multiple versions of AS2



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.

******************************************************* 
This email has originated from Perwill plc (Registration No. 1906964) 
Office registered at: 13A Market Square, Alton, Hampshire, GU34 1UR, UK 
Tel: +44 (0)1420 545000 
Fax: +44 (0)1420 545001 
www.perwill.com 
******************************************************* 
Privileged, confidential and/or copyright information may be contained 
in this email, and is only for the use of the intended addressee. 
To copy, forward, disclose or otherwise use it in any way if you are not 
the intended recipient or responsible for delivering to him/her is
prohibited.
If you receive this email by mistake, please advise the sender immediately, 
by using the reply facility in your email software.

We may monitor the content of emails sent and received via our network 
for the purposes of ensuring compliance with policies and procedures. 
This message is subject to and does not create or vary any contractual 
relationships between Perwill plc and the recipient. 
******************************************************* 
Any opinions expressed in the email are those of the sender and not 
necessarily of Perwill plc.
******************************************************* 
This email has been scanned for known viruses using 
McAfee WebShield 4.5 MR1a 
*******************************************************