Re: Copy-edit comments on filexfer-08

[Joseph Galbraith <galb-list%vandyke.com@localhost>]

der Mouse wrote:
> > (I believe this round introduced one incompatible change.  [...])
>
> It might help to call out what it is.  I assume you're talking about
> the REALPATH change, but it could also be the version-select switch
> from uint32 to string.  (Your reply makes it clear *you've* been
> thinking of the latter as a string, but that's not what it said.)

Sorry... you're right, it was the REALPATH change.

> > > uint64s.  Is there any reason they aren't simply 16-bit fields
> > > (probably uint32 on the wire), with each bit indicating whether a
> > > particular combination is supported?
> >
> > Well, I set out to do it that way originally, but it was easier to
> > specify this way.  Can you come up with some language that specs it
> > reasonably clearly with adding a whole bunch of new identifiers?
>
>
> Probably.  Let's see, how about this (using supported-open-block-masks
> for the sake of argument):
>
>            uint32 supported-open-block-masks
>
> (actually, I'd prefer uint16, but I don't think we have one - maybe put
> both block-masks in a single uint32?)

How about we simply define one?

>    supported-open-block-masks
>       A 16-bit mask specifying which combinations of blocking flags are
>       supported.  Each bit corresponds to one combination of the
>       SSH_FXF_ACCESS_BLOCK_READ, SSH_FXF_ACCESS_BLOCK_WRITE,
>       SSH_FXF_ACCESS_BLOCK_DELETE, and SSH_FXF_ACCESS_BLOCK_ADVISORY
>       bits from Section 7.1.1.3, with a set bit corresponding to a
>       supported combination and a clear bit an unsupported combination.
>       The index of a bit, bit zero being the least significant bit,
>       viewed as a four-bit number, corresponds to a combination of flag
>       bits, shifted right so that BLOCK_READ is the least significant
>       bit.  The combination `no blocking flags' MUST be supported, so
>       the low bit will always be set.
>
>       For example, a server supporting only the classic advisory read
>       (shared) and write (exclusive) locks would set the bits
>       corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY,
>       0b1010, plus the always-set bit 0b0000, giving a mask value of
>       0b0000110000000001, or 0x0c01; a server supporting no locking at
>       all would set only bit zero, giving 0x0001.
>
>       Bits other than the low 16 are reserved for possible future use
>       and MUST NOT be set.
>
> The last sentence does not apply if both masks are packed into a single
> uint32, of course.

Great, I'll use this then (barring the last sentance.) I think I'll
introduce uint16 in the data-types section... then if you (the
collective you) want to considered it a packed uint32, you can,
but it'll be speced seperately, which is the nicer way to do it.

> > I've changed it to read:
>
> >    Typically, the client SHOULD NOT down-grade the protocol version
> >    using this extension; however, it is not forbidden to do so.  One
> >    reason a client might do so is to work around a buggy implementation.
>
> > Is that better?
>
> Somewhat.  There is still the implication that of two versions, one
> will be a downgrade compared to the other, which, even if it's true
> now, surely will not remain true forever.  However, I think the
> implication is loose enough that that language is OK.
>
> I'm still not clear whether totally non-numeric version strings are
> acceptable or not.  I see nothing that would forbid, say,
> "illuminati%fnord.mil@localhost" from appearing in the list, nor any simple way
> to decide whether it would be a downgrade as compared to
> "infibulated-gonkulator%example.net@localhost".  But if you're going to allow DNS
> extensibility at all, that is, ultimately, unavoidable - it's entirely
> possible that of two "private" versions, neither is a feature subset of
> the other, regardless of how they're named.

I'll explicitly allow non-numeric values (that was the intent.)

Nico suggested that we could even allow a-la carte implementation
of v6, such as attrib-v6, which would imply whatever version was 
previously in use, but using v6 attributes.  (I'd probably actually
allow "3,attrib-v6" as the response, indicating v3 w/ v6 attributes,
and specifically disallow two 'numeric' items in the response.)

I haven't gone that route... because I'm not convinced it would
convince any more people to migrate to v6 (or even to get the
benifits of just v6 attributes.)

And it would complicate implementations even more and I've got
people complaining as is.

Thanks,

Joseph