Re: [Gnu-arch-users] multi-committer functionality revisited

[Tom Lord]

    > From: address@hidden

    > You are looking for the part where its made clear that
    >     file%uname=002:bla
    > is pointing to another port/application/implementation then
    >     file%uname=077:bla

Would it have been too much trouble for you to say:

        see section 1.2 where it says

           "Although many URL schemes are named after protocols"
                     ^^^^

which appears to be what you're talking about?  I mean that's it --
that _phrase_ (emphasis added) is the best support I can see for your
position.  Is there something else you're thinking of?

_Ports_ by the way are addressed in section 3.2.2 and "application"
and "implementation" are not used in the RFC in the senses that you
seem to imply.


Section 3.1 seems to me to be the most relevent to this and it 
supports my idea but demands a different syntax, using only permitted
characters:

       file.umask002:
       file.umask077:

I like that approach rather than using the other permitted punction (+
and -) because then:

       file.umask-002:
       file.umask+070:

can later have a distinct and useful meaning.

It seems unwise to try to put umask info in the <authority> part of
the url, especially for sftp and then for local files for consistency.
(See section 3.2.2 which defines a syntax for ip-based protocols to
use.)

The last remaining sane possibility (other than making up an entirely
new syntax for pahts) is to make the umask a parameter to some path
component:

        file.umask:/path/to/archive;umask=077
        sftp.umask://<hostfoo>/path/to/archive;umask=002

however, that seems fairly gratuitous and inconvenient to me.  
For example, I could not then cut and paste the stuff to the right of
the : into a file or sftp URL.   And if the path to my archive
contains a ;, then it would need to be escaped before being handed to 
register-archive.

It is, indeed, truly sad that the "scheme" syntax is sufficiently
anemic as to make parameterized protocols more difficult than
necessary to name but I see nothing that precludes them and they seem 
like a quite sane idea to me.

-t