ietf-mta-filters
[Top] [All Lists]

Re: notification options

2006-07-27 06:04:05

On Tue, 2006-07-25 at 17:39 +0100, Alexey Melnikov wrote:
William: 5th choice: have an extra parameter with string only in ascii.
Kjetil doesn't think that having 2 strings, one in ascii is confusing

just a small note:  I meant "one in English (and therefore ASCII)".
after all, most of us can not assume that all our correspondents
understand our mother tongue, so it would be useful to cater for a
lingua franca (or even more than one).

Notifications:
- Change :options to be multiple ':option <name: string> string/number'?
The current syntax is too flexible and is also incorrect (e.g. no place 
for option name).

we've just agreed multiple ":option" is illegal :-)

I really don't see why we need the ":option" indirection, what's wrong
with declaring/explaining all possible options as tagged arguments in
each specific notification method extension?

- What is the initial list of :options? IANA registry?

"subaddresses" adds tagged arguments without declaring them in any IANA
registry.  I don't think we need one.

- Method registry? (Can include options).

Alexey: do we want to do an IANA registry now (there are no options so 
far) or later when the first one is needed?
Many: do the IANA registry now, don't be lazy.
Chris gives an example for options: :option "alarm" "audio".
Kjetil: generic options valid for all methods should be explicit :keywords.
Some options would be method specific, but some might be generic, so 
options registry should be separate from method registry. Consensus to 
create the two registries in the document.

-- 
Kjetil T.


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