zip64 format not streamable?

Zippers,

I was going to write an example unzipper and started to look at the new 
zip64 format.  My intent was to write a streaming unzipper, i.e. one 
that does not seek in the zip file.  Reading PKWare's appnote leaves 
something indeterminate.  If a streaming zipper writes a local header 
with no length or crc information, setting bit 3 of the flags in the 
local header, then the compressed data is followed with a data 
descriptor that has the lengths and the crc.  That has been the case 
for many years since we got them to put that in their appnote when 
deflate first came out.  However in the new appnote it says: "for Zip64 
format archives, the compressed and uncompressed sizes are 8 bytes 
each" in that data descriptor.  However when bit 3 is set nothing 
preceding that will provide any indication that this is a "Zip64 format 
archive".  So is it four byte or eight byte lengths?

Also this seems to go against the other instances of the zip64 format, 
where a zip64 extra field only appears when needed, in which case the 
old length fields are set to all ones to indicate the presence of the 
extra field.  But when bit 3 is set, the length fields are set to zero.

So has PKWare screwed up the format so that it isn't streamable, or am 
I reading something wrong?  Or maybe if the version is > 45, it's a 
"Zip64 format archive", and the data descriptors always have eight-byte 
lengths?

mark