Works for me: I had suggested “proprietary”, so I will now unsuggest it. Authors, sorry about that: please remove that word in both places the next time you make a revision. Thanks.
Barry
On Sun, Oct 13, 2019 at 1:29 PM Paul Hoffman <paul.hoffman@xxxxxxxx> wrote:
On 13 Oct 2019, at 7:25, Barry Leiba wrote:
>> The Abstract ans Section 1 say: "This is a non-standard proprietary
>> extension." I understand that this is not a standards track document,
>> so
>> the "non-standard" part makes sense. However, what is the point of
>> publishing a "proprietary" extension as an RFC. I would hope that
>> interoperable implementations is the goal of publication.
>
> I’m afraid this addition is my fault. Perhaps “proprietary” is
> the wrong
> word here: The point is that this is documenting an extension
> developed by
> one registry and not in use by others, with the idea that if others
> want to
> use it they can follow this to interoperable. It’s rather like when
> we
> documented Apple Bonjour as Informational.
>
> Better word?
Why have any word other than "non-standard"? It is *not* proprietary in
that multiple vendors implement it and there appears to be no licensing
requirement from the authors.
--Paul Hoffman
