[Top] [All Lists]

Re: Straw consensus call on auth-header draft

2008-10-13 14:10:55

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


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.


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.


<Prev in Thread] Current Thread [Next in Thread>