RE: Protest: Complexity running rampant
I don't think this is an issue worth objecting to. Complexity exists at many levels. There is complexity of specification and complexity of implementation. The two are not the same. I can imagine two reasons why I might want to have ASN.1 in XML. The first is that I want to use a single set of tools for data serialization and unpacking. This is particularly attractive if I was going to use an ASN.1 structure inside an XML packet. The second is if I was looking for a way to move from a legacy ASN.1 base to an XML base. As far as complexity of architecture goes neither ASN.1 not XML are to my taste. ASN.1 looks like a briliant idea that went into committee and got broken by a few participants whose political skills exceeded their technical skills. This is a real problem in data formats since they appear to be simple enough that everyone can have an opinion. ASN.1 is not so bad unless you have to either use the seriously derranged DER encoding or deal with some of the later additions to the data model. DER would not have been so bad if they had chosen to use indefinite length encoding for lists rather than definite length, thus requiring implementations to chose between unnecessary recursion and unnecessary memory copies. I recently wrote an ASN.1 unpacking routine in Javascript in a few hundred lines. It is not that difficult (packing is another matter - ugh!). XML syntax is not that bad either. The problems are mostly due to XML schema which makes the unfortunate mistake that C++ made of not jetisoning the all cruft from C and starting fresh. The prefix scheme is neither necessary nor convincing in my view. It breaks the principle that the choice of modular decomposition in a design should not constrain the end result. In other words the fact that XML Encryption is built on XML Signature should not be visible when reading a document that is based on both. I don't see that the 'complexity' of XML or ASN.1 is unreasonable though. The problems come from issues such as modularity and version control that have always been tricky. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Eric Rescorla has agreed to deal with the third party disclosure on my behalf. thanks for all the volunteers of help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Another disclosure on draft-housley-tls-authz-extns
Folks, it should be surprising to no one here that we've recieved the following disclosure; it is a direct result of my mail yesterday. I'd ask the community to evaluate this potential IPR in addition to the disclosure from Redphone. --- Begin Message --- Dear Russ Housley, Mark Brown: An IPR disclosure that pertains to your Internet-Draft entitled "Transport Layer Security (TLS) Authorization Extensions" (draft-housley-tls-authz-extns) was submitted to the IETF Secretariat on 2007-02-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the IPR disclosure is "Eric Rescorla's statement about possible IPR claimed in draft-housley-tls-authz-extns-07.txt belonging to IBM Corporation." The IETF Secretariat --- End Message --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Re: Last Call: draft-mcwalter-langtag-mib (Language Ta g MIB) to Proposed Standard
On 2/27/07, McDonald, Ira <[EMAIL PROTECTED]> wrote: Yes - from the IEEE/ISTO Printer Working Group, see the Job Monitoring MIB (RFC 2707) which defined the textual convention 'JmNaturalLanguageTagTC' Ah, silly me, I forgot that I hadn't written the part that populates the database with TCs yet. I wrote that part and indeed found JmNaturalLanguageTagTC. Interestingly, I couldn't find any objects that used this TC, in Job-Monitoring-MIB or any MIB published in an RFC. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Protest: Complexity running rampant
Hi - > From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> > To: "Harald Tveit Alvestrand" <[EMAIL PROTECTED]>; "Fred Baker" <[EMAIL > PROTECTED]> > Cc: > Sent: Tuesday, February 27, 2007 6:45 AM > Subject: RE: Protest: Complexity running rampant ... > DER would not have been so bad if they had chosen to use > indefinite length encoding for lists rather than definite length, > thus requiring implementations to chose between unnecessary > recursion and unnecessary memory copies. ... There's a third approach that can be simpler to implement and faster to execute - do the encoding *backwards*, starting at the end of your buffer. Then you don't need to encode the length (and length-of-length) fields before you know their values. That way one can do the encoding without recursion or unnecessary copies, and ensure that all lengths are minimal. Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
