Lisa Dusseault wrote:
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.
It isn't? Since your language was "normatively * some kind of feature
advertising" then I am entirely confused. The feature advertising for this
does
not yet exist.
You cite normatively referring to such advertising. How did I mis-characterize
your query?
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.
That's useful input, since it can level-set folks' expectations.
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.
Hmmm. Maybe it's jet-lag. I'm not thinking of which ones you might have in
mind.
I'd really appreciate some particulars, for advertising security-related
features that rely on being within a trust boundary and are widely adopted and
used. What existing mechanisms qualify?
Thanks.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html