[
Lists Home |
Date Index |
Thread Index
]
It is wrong to say that use of an abstract syntax notation is in any way in
conflict with the desire for running code before a standard is finalised. I
fully support the latter as a very desirable objective, but it in no way
dictates the way the messages are defined. As an aside, the Standards for the
last two pieces of major development in ASN.1 were deliberately delayed until
feed-back was available from implementations.
John L
Amelia A. Lewis wrote:
> On Mon, 3 Nov 2003 15:48:45 -0500
>
>>understanding of it. The ASN.1 approach of designing with abstract
>>syntax and then using deterministic translations to concrete syntax
>>greatly improves the effectiveness with which a protocol can be
>>communicated. The result should be higher interoperability.
>
>
> See RFC2116 for a definition of SHOULD. Also check some of the cynics
> on the net (findable via google) on whether "SHOULD" should ever appear
> in a specification.
>
> SHOULD didn't happen.
>
>
>>>the notion that there's no re-use between protocols in the
>>>Web/concrete approach is just silly; HTTP is
>>
>> As I'm sure you realize, I was refering to things like Telnet,
>>FTP, SMTP, SNMP, NNTP, etc. which have completely divergent code bases
>>above the TCP/IP layer. The history of protocol development is made up
>
>
> No. They. Don't.
>
> All of these protocols are based on the concept of the "network virtual
> terminal", a device long since outmoded (it only does ASCII, and prefers
> not to see most control characters, but especially hates 0x0).
>
>
>>of these isolated efforts and it was this history that your original
>
>
> I can send some hyperlinks to RFCs, or to mailing lists dedicated to the
> history of internet protocol development. In a word, though, your
> assertions are incorrect and conclusions drawn from them are thus likely
> to be on shaky ground.
>
>
>>mailing seemed to be refering to. Reuse of protocol components on the
>>Internet has been a rare and primarily recent phenomenon. (With some
>
>
> Horsefeathers. Do the research.
>
>
>> Are you saying that just because it has worked in the past we
>>shouldn't try to do better? In any case, an argument for ASN.1 is not
>
>
> I think it's a challenge to show that it can be done better, before
> you're going to get people to give up working tools. This is the same
> argument that came to a conclusion at the IETF in 1992: here's this
> grand, abstract, wonderful OSI protocol stack, complete with abstract
> syntax notations and everything totally comp-sci. No working code,
> though. The IETF requirement for two independently developed,
> interoperating (and complete) implementations was apparently too great a
> burden for the potential reward. Rough consensus says: no running code,
> no brass ring.
>
> Amy!
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services Ltd)
1 Blueberry Road
Bowdon j.larmouth@salford.ac.uk
Cheshire WA14 3LS
England
Tel: +44 161 928 1605 Fax: +44 161 928 8069
|
