Nico, I understand your explanations on both of my comments, so my summary is that the text in the draft is not quite clear enough for a newcomer to the issue. While that is often the case for technical documents, I think another couple of sentences culled from your explanations would make the draft more robust. (Especially since the point of the draft is to clarify something that was left unclear by the previous RFCs.)
Thanks Brian On 2008-11-04 05:58, Nicolas Williams wrote: > On Mon, Nov 03, 2008 at 02:47:02AM -0600, Nicolas Williams wrote: >> On Mon, Nov 03, 2008 at 11:10:20AM +1300, Brian E Carpenter wrote: >>> Comments: >>> >>> Here, then, is a generic re-statement of this structure, in pseudo- >>> ASN.1: >>> >>> What's pseudo-ASN.1? This is normative, so why isn't it ASN.1? >> RFC2743 lays out the *abstract* API for "generic security services". >> >> RFC2743 uses "pseudo-ASN.1". >> >> I kept the style of RFC2743. > > I should add a bit more about RFC2743 here. > > RFC2743 uses pseudo-ASN.1 for two distinct things: > > - To specify a small amount of on-the-wire bits. > > For this true ASN.1 and DER would have been better, of course. > > > - To specify the types of function input arguments and output results. > > RFC2743 uses only "scalar" (in the Perl5 sense) or simple (in the > ASN.1 sense) types. Everything's an OCTET STRING, an OBJECT > IDENTIFIER, an INTEGER, or some type made up for RFC2743 (e.g., > CREDENTIAL HANDLE). > > RFC2744 changed the type of one argument, channel bindings, to be > structured, no longer scalar. > > This I-D uses pseudo-ASN.1 to model that now-structured view of channel > bindings imposed by RFC2744. This I-D also provides an encoding for > this structure, but the encoding is not a ASN.1 encoding (not BER, DER, > CER, PER nor XER). The chosen encoding (from RFC1964/RFC4121) is not > one of the standard encoding rules of ASN.1 because there already exist > implementations of the chosen encoding -- we're promoting code re-use. > > Mechanism designers are, however, left to choose their own encoding if > they don't like the one from RFC1964/RFC4121. > > Nico _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
