Re: filexfer draft ready for last call?

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> First, of course, it still has most of the same character-set issues
>> it always did.  [...]

>> The simplest fix I see is to add a special charset-name for the
>> filename-charset extension which means, basically, "raw octet
>> sequences".  (For concreteness, I suggest "RAW-8BIT".)
> So you proposal is that we continue to require the server do best
> effort translation to UTF-8 unless the client turns this off;
> however, we allow the server to advertise that what you are likely to
> get if you turn off is RAW-8BIT?

Yes.  Basically, a way for the server to say "my filenames are
charset-blind octet sequences; if you insist on UTF-8 you're likely to
get unpleasant surprises".

> The only change being that we allow the server to specify something
> that basically says I have no clue about the char-set of the
> filenames.

Right.

> I can live with that-- but it still seems more useful to have the
> server give some guess as to the content.

Possibly; it depends on whether you think a guess made with no
information behind it is more or less valuable than the information
that there is no information on which to base a guess.  I can see it
going either way, depending on the context.

>>>    supported-attribute-mask
>> Also, it's not clear whether this means "the client may want do this
>> to make things easier on the server" or "the server is allowed to
>> silently apply this mask".
> I've changed it to be 'applied by the client.'  Also, does the
> discussion after the list make this any clearer?

Somewhat.  I'm glad to see it clarified at the point of definition,
though.

>>>    This protocol uses the following values for the symbols declared
>>>    in the POSIX standard.  [...]
>>>    Implementations MUST NOT send bits that are not defined.
>> This makes it impossible to send, for example, VMS "delete
>> permission" bits.  Is this really desired, or is this being left up
>> to implementation experimentation before standardization?
> But no one would know how to interpret those bits--

That depends.  If the sftp spec says that these bits indicate delete
permission, then everyone knows what they mean, even if they might not
have any good local analog available.

In other respects, sftp seems to try to be a union of all the common
possibilities (eg, the way it handles locking); it seems odd for it to
take the opposite tack when it comes to permission bits.

> I'd be happy to add the VMS bits.  I'd probably need at least some
> rough description of what needs to be added (if I remember correctly,
> doesn't VMS also have a SYSTEM field -- four fields of four bits
> each?)

That sounds right; it's been far too long since I used VMS, though, so
I'd have to go ask someone who still uses it, or dig up some docs.

>>>       The file is on read-only media, or the media is write protected.
>>>       [...] because there is no media available in the drive.
>> "media" is plural [...].
> Uggh... there is no medium in the drive or are no media both sound
> strange to me.  Are you sure that 'media' isn't really pretty much
> used as a singular noun in spite of what the dictionary says?

Hmm.  Actually, I think a good case could be made that it is becoming
(or perhaps even has become) a mass noun (at least when applied to
computer storage).  And mass nouns usually act grammatically singular,
so you are probably right.

I usually try to reword the sentence to avoid depending on the number
of "media".  In these cases, I'd perhaps try

	The file is on read-only (or write-protected0 media.
	...because the drive is empty.

On reflection, I now think that rewording is best, with leaving it the
way it was is second best.  Switching to plural at least has historical
pedantry on its side, though it feels sufficiently odd to my modern eye
to relegate it to third place for me.

>> Or perhaps SSH_FX_BYTE_RANGE_LOCK_REFUSED should be returned for
>> [SSH_FXP_BLOCK conflicts]?  The description of SSH_FXP_BLOCK doesn't
>> say.
> Indeed, SSH_FXP_BLOCK does return SSH_FX_BYTE_RANGE_LOCK_REFUSED.
> SSH_FX_LOCK_CONFLICT is returned from SSH_FXP_OPEN.

Just in case: I trust you made SSH_FXP_BLOCK call out which it uses?

> Wholly compromising the server does pretty much follow from
> manipulating files at will... in your example, manipulating files at
> will isn't possible.

Well, I suppose it's a matter of interpretation of what "at will"
means.  I'm not about to lose any sleep over it, especially since to my
eye the rewording you gave fixes it.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B