Re: 2806 parameter optionality

> *    Parameters that are mandatory in action
> - the recipient must both understand AND to act on the parameter, or 
> else reject use of the whole URI; action on the parameter is a MUST
> 
> *    Parameters that are mandatory to understand
> - the recipient must understand the parameter, but is free to ignore it 
> if it has good reason so to do; action on the parameter is a SHOULD
> 
> *    Parameters that are purely optional. (This class implies the same 
> behaviour as specified in the original RFC2806)
> - the recipient of such a parameter can simply ignore the presence of 
> the parameter if it is not understood; action on the parameter is a MAY
> 
> In RFC2806bis, mandatory parameters are proposed to have 'm-' as the 
> first two characters of their label.
> 
> Examples of this kind of parameter are the ones in James' parameter draft).
> James, although this is off-topic for the main 'tel:' URI update, how do 
> you see your parameters?
> 
> Do folks think that:
> (a) the presence of a 'm-' string in a parameter label puts it into the 
> first or second category?
> (b) there should be a way of indicating the other mandatory category?

In the interest of simplicity, I would argue that there are only two 
categories, defined by externally observable action:

- m-: if the client does not know the parameter, it must reject the URI 
(by rejecting the SIP request that contained it, for example, presumably 
in a manner similar to receiving an unknown URI scheme). The action for 
the parameter can itself be advisory, although that seems a bit odd.

- Otherwise: the receiver can act on or ignore the parameter.

I don't see how a third category can be usefully observed from the 
outside. SHOULD and MUST are not descriptions of behavior, they are 
descriptions of implementations.

> 
> all the best,
>   Lawrence