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.
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.
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?
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?)
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.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html