Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> 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 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 > > 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). > > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html