On Oct 12, 2008, at 4:44 PM, Dave CROCKER wrote:
Lisa Dusseault wrote:
I'd like to do a more explicit consensus call now to nail this
down. I've tried to identify the major points of attraction rather
than every variant, to see where people are leaning. Please reply
with one of these options, a variant, and explanation if you like:
A) auth-header to not require any feature advertising or auto-
configuration
B) auth-header to normatively RECOMMEND some kind of feature
advertising
C) auth-header to normatively REQUIRE some kind of feature
advertising
Lisa,
Your alternatives B & C appear to seek normative technical language
that refers to something that does not exist. Further, a phrase
like "some kind of" makes it rather difficult to know whether the
'requirement' is satisfied.
Yes, this is correct. I realize this is somewhat of a charter-phase
question, but that's a risk with individual submissions going for
Proposed Standard -- the risk that without a consensus-based charter,
the scope of the work will be questioned.
It is generally ill-advised to have a specification make statements
about the unknown future, which of course means anything in the
future. It seems an even poorer choice to make that statement be
normative, without specifying the details of that future precisely.
Agreed.
So, please clarify how can a technical specification contain
normative language to cover something that doesn't exist? More
precisely, what does it mean to include such language, in terms of
actual development or operation? What impact does such a statement
have on the current specification? On use of it?
Since that's not what I'm suggesting, I can't answer these questions.
The alternative seems to be to require the current specification to
wait until there is an approved specification for advertising/
configuration that can then, in turn, be recommended or required
(presumably SHOULD OR MUST, respectively?)
That could be.
ps. But to conform to the precise confines of your exercise, I
suggest Alternative A, since there are many operational environments
for which manual configuration works just fine. In those
environments, advertising and configuration mechanisms add
complexity without benefit.
pps. What are examples of similar mechanisms, for application-level
advertising or auto-configuration, that are already in Internet-
scale use? Knowing the answer to this can give some guidance about
the likely risk of mandating such a mechanism here.
IMAP and SMTP have lots of application-level capabilities
advertising. Sometimes this can aid auto-configuration.
Lisa