Jakub Narebski [off-list ref] writes:
1. Server sends space separated list of capabilities it support. It
MUST NOT send capabilities it *does not* support. It MAY NOT send
"include-tag" if there are no tag objects (or is it SHOULD NOT?).
I doubt RFC 2119 lingo would include MAY NOT, as it is ambiguous
especially to non-native speakers (like me). You meant to say "MAY omit
sending", perhaps, but in general capabilies are what you _can_ do at the
protocol level, and in my opinion, you shouldn't have to check if a
particular repository you (as a program with given set of features
implemented) happen to be looking at has tags in order to decide what
capabilities to advertise.
2. Client sends space separated list of capabilities it wants. It SHOULD
(or perhaps it is MAY?) send subset of server capabilities, i.e do
not send capabilities served does not advertise.
I'd say "the client SHOULD NOT ask for capabilities the server did not say
it supports".
3. Server MUST ignore capabilities it does not understand. Server MUST
NOT ignore capabilities (or SHOULD NOT only?) that client requested
and server advertised.
I know unrecognized capability requests are silently ignored, but I
consider that as a sloppy/practical programming, and not a specification.
Junio C Hamano wrote:
Jakub Narebski [off-list ref] writes:
quoted
1. Server sends space separated list of capabilities it support. It
MUST NOT send capabilities it *does not* support. It MAY NOT send
"include-tag" if there are no tag objects (or is it SHOULD NOT?).
I doubt RFC 2119 lingo would include MAY NOT, as it is ambiguous
especially to non-native speakers (like me).
You are right, RFC 2119 does not include MAY NOT.
You meant to say "MAY omit
sending", perhaps, but in general capabilies are what you _can_ do at the
protocol level, and in my opinion, you shouldn't have to check if a
particular repository you (as a program with given set of features
implemented) happen to be looking at has tags in order to decide what
capabilities to advertise.
I wonder why in http://book.git-scm.com/7_transfer_protocols.html
("Git Community Book", chapter "7. Internals and Plumbing", section
"Transfer Protocols", subsection "Fetching Data with Upload Pack")
"include-tag" is not included ;) in advertised server capabilities.
Because github's git-daemon advertises it even if there are no
tags present
$ echo -e -n "0039git-upload-pack /schacon/gitbook.git\0host=github.com\0" |
nc -v github.com 9418
Connection to github.com 9418 port [tcp/*] succeeded!
00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag
00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration
003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master
003edc9d991bc43cb04e692efc793f885eb4ff7fda98 refs/heads/pt_BR
quoted
2. Client sends space separated list of capabilities it wants. It SHOULD
(or perhaps it is MAY?) send subset of server capabilities, i.e do
not send capabilities served does not advertise.
I'd say "the client SHOULD NOT ask for capabilities the server did not say
it supports".
I agree that it is better formulation (phrasing).
quoted
3. Server MUST ignore capabilities it does not understand. Server MUST
NOT ignore capabilities (or SHOULD NOT only?) that client requested
and server advertised.
I know unrecognized capability requests are silently ignored, but I
consider that as a sloppy/practical programming, and not a specification.
Well, the whole 'be strict in what you send, and accepting in what you
accept' leads unfortunately to accepting sloppy programming and coding.
Nevertheless it is I guess better to silently ignore unknown
capabilities requested by client than fail, isn't it?
--
Jakub Narebski
Poland