[Ietf-not43] MUST/SHOULD protocol/service schism
Andrew Newton
anewton@ecotroph.net
Wed, 22 Jan 2003 14:02:56 -0500
In rewriting the requirements draft so that MUST/SHOULD language is not
used for service descriptions, a problem has been made more evident.
First, the current draft actually rarely uses the word "protocol",
instead using "service" in places where we would naturally want to say
protocol. So if we went through the draft and strictly changed the
capital case in those places, the draft actaully won't specify too much
of anything.
So I went back and changed the word "service" to "protocol" in places
where the requirement was about a protocol issue. However, now the
draft has a schizophrenic feel. Here are a few examples:
The protocol MUST provide the capability of searching for
registrants, within limits set by the policy of an operator, by exact
name match or a reasonable name subset. This search must comply with
Section 3.2.8.
The service must provide a mechanism to distribute this search across
all applicable domain registries and registrars. The protocol SHOULD
have a means to narrow the scope of a search to a specific TLD. The
protocol MUST be able to specify an empty result set should the
search yield no results.
and
The protocol MAY allow the ability, within the limits of the
operator, to list all domains hosted by a specific nameserver given
the fully-qualified host name or IP address, if applicable, of the
nameserver. The service may provide a mechanism to distribute this
search across all applicable domain registries and registrars.
I do not think this makes it clear that the service requirements are
OPTIONAL depending on the policy of an operator. It is confusing.
I'd like to restructure the document so that service model descriptions
are separated from the client/server protocol interactions. I think by
placing them in separate sections, it would be clearer. The MUST/SHOULD
language on the service descriptions would be lowercased or removed
altogether.
Please let me know what you think. I'd rather get out a good document
than one that can't be understood by anybody.
-andy