: RFC 3588 typos (fwd)

---------- Forwarded message ----------
Date: Mon, 12 Dec 2005 18:45:58 -0800
From: "Pat Calhoun (pacalhou)" <[email protected]>
To: Bernard Aboba <[email protected]>
Subject: FW: RFC 3588 typos

Any ideas how you want to deal with these? 
 

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 


________________________________

	From: Anno Langen [mailto:[email protected]] 
	Sent: Monday, December 12, 2005 1:08 PM
	To: [email protected]
	Cc: [email protected]; Paul Devine
	Subject: RFC 3588 typos
	
	

	Dear Mr. Calhoun

	 

	http://www.rfc-editor.org/errata.html asks to verify errors with
the authors before sending them to [email protected]. Please
look these over.

	 

	I see multiple typos in section 3.2. (Command Code ABNF
specification) of RFC 3588

	*         Missing opening quote of the literal,
"Diameter-Header:" in the header production

	*         Extra quote before Diameter-Header: in the
Example-Request

	*         Missing closing bracket at the end of Example-Request

	*         None of the actual request specifications in the RFC
conform to the grammar. Is this due to typos in the grammar and example?

	*         All use a space instead of hyphen in "Diameter
Header:" 

	*         All use angle brackets around the command-name in
command-def

	*         As an aside, 3GPP TS 29.329 V6.6.0 publishes request
specifications with multiple "required" and "optional" diameter-message
parts. Why does the grammar not allow "header fixed* (required |
optional)* fixed*"? 

	 

	In section 4.4 (Grouped AVP Values) the literal "AVP-Header:"
has a hyphen, but all AVP headers in the RFC, including the example
following the grammar, use space instead. Is this a typo in the grammar?

	 

	In section 5.6.4. (The Election Process)

	*         "it length" should be "its length" in:   "The
comparison proceeds by considering the shorter OctetString to be padded
with zeros so that it length is the same as the length of the longer,
then performing an octet-by-octet unsigned comparison with the first
octet being most significant."

	*         Apart from the typo, the election section has resulted
in different implementations. In the quote above "padded with zeros"
doesn't specify where the padding occurs. Personally, I assume padding
at the end rather than the beginning. But the sentence following this
quote above has me really confused. "Any remaining octets are assumed to
have value 0x80." Should the sentence be stricken? What octets remain
after padding with zeros? OpenLdap pads with 0x80 rather than zeros at
the end of the shorter OctetString. Was that the intention?

	 

	Thank you in advance for your time to look this over

	 

	      Anno

	Notice: This email message, together with any attachments,
contains information of BEA Systems, Inc., its subsidiaries and
affiliated entities, that may be confidential, proprietary copyrighted
and/or legally privileged, and is intended solely for the use of the
individual or entity named in this message. If you are not the intended
recipient, and have received this message in error, please immediately
return this by email and then delete it.