Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt

[Ned Freed <[e-mail]>]

> On 2012-03-21 03:34, Barry Leiba wrote:
> >> [Relatively] Minor Issues:
> >> I'm not so sure about use of RFC2119 language in the IANA Considerations
> >> section.  You're not really describing interoperability requirements with IANA.
> >
> > I'm sure.  And it's my text -- this is one that Mykyta doesn't like.
> > The three MUSTs in there are not directed at IANA, but at people
> > writing new registrations.  They tell those people what their
> > registrations have to look like, and I wanted to use MUST to stress
> > that even though this is an FCFS policy, there are requirements
> > nonetheless.
> > ...

> I'm with Murray here. This is something RFC 2119 keywords are not for.

The about: URI registration procedure can do whatever it wants to - the usage
of RFC 2119 compliance language there is pretty limited and I don't think it
will make a significant difference either way.

That said ...

<rant>

The notion that this usage was inappropriate is overly pedantic nonsense.
Nothing more and nothing less.

Both RFC 1123 and RFC 2119 agree: Compliance keywords are used in the context
of compliance with a specification. There doesn't have to be a protocol,
format, or anything else involved.

Now, RFC 2119 does go further and talk about when compliance language needs to
be used in order to insure interoperability. But nowhere does it say, or even
imply, that interoperability considerations are the sole justification for
using these terms.

And even if it did, so what? Are you seriously going to try and argue that
failure to follow these or any other registration mandates can under no
circumstances cause interoperability problems? No, I didn't think so.

Besides, we've been using compliance language in registration procedures
for a long time. The media types registration procedure is one example; other
messages have pointed out various other ones.

And as for Alexey's question about who enforces these rules, in the case of
registration procedures that would be the registration process itself. The
media types registration form won't accept invalid values for many fields.  And
I refuse to accept violations of the MUSTs and push back on violations of the
SHOULDs in media type registrations on a regular basis.

And even if this weren't true, I again have to ask: So what? I haven't noticed
the Internet Protocol Police arresting any of the MIME scoff-MUSTs out there.

In fact I'd have to say that in the case of a registraton process, these
keywords are actually carry more weight than they do in protocol
specifications.  Fail to meet a MUST in a registration document, your
registration is rejected. Whereas in protocol implementations often as not they
are seen as, well, suggestions.

And finally, I thought making registrations processes easier for people to
use was something of an overarching goal here. To that end, don't you
think highlighting the actual requirements in these document so they stand
out at least a little might be somewhat helpful to the casual reader?

</rant>

				Ned