Subject: [IPTEL] 2806 parameter optionality

From: Lawrence Conroy <[email-masked]>
Date: Sun, 2 Jun 2002 17:40:24 +0100

Hi Henning, James, folks,
   whilst working on a parameter for use with the tel: URI scheme, I 
was slightly confused by the classification of mandatory and optional 
parameters.

It seems to me that there are actually three classes of 
externally-defined parameters:

*    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?

all the best,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:
_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 02 Jun 2002 12:52:55 -0400

> - 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 parameter if it is not understood; action on the parameter is a MAY
> 
> 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?

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.

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 2 Jun 2002 19:17:12 +0100

At 12:52 pm -0400 2/6/02, Henning Schulzrinne wrote:
>- 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.
>
To which I reply:
  Many Thanks, Henning,
Wanted to raise it, but am happy with the answer.
(It simplifies any parameter drafts, so is a Good Idea :).

I thought that using a URI whilst ignoring a m-parameter like rn
may be externally observable, so I misunderstand the above.

Re advisory action being Odd - yes it is, but under certain circumstances
the 'recipient' of such a parameterised URI may not share trust with the
'sender', so may choose to reconstruct the parameter.

all the best,
   Lawrence