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 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. -- 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