Subject: Re: MUSTs and SHOULDs [was RE: [Sipping] new draft on overload control in SIP]

From: Miguel Garcia <[email-masked]>
Date: Wed, 01 Mar 2006 09:59:16 +0200

Dean Willis wrote:
> 
> 
> Bad example from draft-ietf-sipping-uri-list-message-05.txt:
> 
>    A UAC that wants to create a multiple-recipient MESSAGE request MUST
>    create a MESSAGE request according to RFC 3428 [8] Section 4.  The
>    UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the
>    MESSAGE URI-list service.  In addition to the regular instant message
>    body, the UAC SHOULD add a URI-list body whose Content-Disposition
>    type is 'recipient-list', specifed in the Framework and Security
>    Considerations for SIP URI-list Services [11].  This body contains a
>    URI-list with the recipients of the MESSAGE.  The URI-list body MAY
>    also include the 'capacity' extension to the URI-list specified in
>    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
>    option-tag, defined in Section 5, in a Require header field.
> 
> 
> Let's look at the "requirements" in the above.
> 
> MUST #1 (create a message request): Why MUST we create a message 
> request? What failure of interoperability occurs if we don't create a 
> message request? We're really trying to say that this service only 
> understands MESSAGE requests as defined in RFC 3428, and that it won't 
> work if you were to use some other kind of request.

The intention in that text is to "import" Section 4 of RFC 3428, which 
is extremely important in this case. Please read such section and tell 
me which normative text we shouldn't import. If we fail to normatively 
refer to Section 4 of RFC 3428, some major implementor who wouldn't care 
about the non-MUSTs could creates MESSAGE requests that are not formated 
accordingly, and wouldn't be understood by the URI-list server.

> 
> SHOULD #1 (populate the request URI): What are the alternatives? What 
> would we want to put in the request URI other than the URI of the 
> target? What happens if we were to put something else here, and how 
> would we compensate if we did? Really, we're not trying to define a 
> requirement here -- we're just describing a use case.

The alternatives is that you write the IM URI of the URI-list server. Or 
that you write even your own URI, but then you need to be sure that the 
request is appropriately routed to the URI-list server. This could be 
done in IMS with filter criteria, but it is not the intention nor the 
normal case.

So, I am not sure if a routability failure can be considered a case for 
lack of interoperability.

> 
> SHOULD #2 (add a URI-list body): Again, what are the alternatives? We're 
> not defining any here. We're just trying to describe a use case.

It is true that we are not defining the alternatives, although a few of 
them exists: the list is already pre-stored in the URI-list server, or 
it is pointed by some content indirection.

> 
> MAY #1 (also include the 'capacity' extension): Why would we want to do 
> that? Fortunately, the "why" is defined in the referenced section 4.1. 
> But are we stating an aspect of optionality that affects 
> interoperability? Nope. We're just describing some information that, if 
> present in the request, will be used in processing the request at the 
> recipient, and if it's not there, it won't be.

I think this MAY is drafted according to the definition of "MAY" in RFC 
2119:

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
    truly optional.  One vendor may choose to include the item because a
    particular marketplace requires it or because the vendor feels that
    it enhances the product while another vendor may omit the same item.
    An implementation which does not include a particular option MUST be
    prepared to interoperate with another implementation which does
    include the option, though perhaps with reduced functionality. In the
    same vein an implementation which does include a particular option
    MUST be prepared to interoperate with another implementation which
    does not include the option (except, of course, for the feature the

> 
> MUST #2 (also include the 'recipient-list-message" option tag): It would 
> be nice to say WHY we do this, although we use this in SIP so much we 
> seem to expect the reader to know. In short, we're using the 
> extension-negotiation mechanism of SIP to make sure that the recipient 
> understands this extension. If we include the option-tag, then a 
> recipient of this request will reject the request with an informative 
> error if it does not understand the extension.

True, but as you mention, we expect the reader to familiar with SIP and 
the Require header. I don't think this draft is a SIP tutorial.

> 
> 
> My suggested rewrite:
> 
>    A UAC that wants to create a multiple-recipient MESSAGE request
>    creates a MESSAGE request according to RFC 3428 [8] Section 4.  

Here is the first problem. So you are describing a use case, that is, 
the behavior of a particular UAC. According to this, if I have another 
UAC that creates a multiple-recipient MESSAGE request by creating an 
MSRP SEND request that contains foo and bar, then it will be compliant 
to this specification, even when such UAC won't be able to interoperate 
with a URI-list server implemented according to this specification. Got it?

>  The
>    UAC populates the Request-URI with the SIP or SIPS URI of the
>    MESSAGE URI-list service.  

Another problem. This is an instance description. But if you have a UAC 
that populates the Request-URI with something else, the consequence 
(unless you really really thought about them) is that the request will 
fail to reach the URI-list server.

> In addition to the regular instant message
>    body, the UAC adds a URI-list body whose Content-Disposition
>    type is 'recipient-list', specifed in the Framework and Security
>    Considerations for SIP URI-list Services [11].  This body contains a
>    URI-list with the recipients of the MESSAGE.  The URI-list body may
>    also include the 'capacity' extension to the URI-list specified in
>    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
>    option-tag, defined in Section 5, in a Require header field.
> 
> Note that the only 2119 language retained here is the final MUST on 
> extension negotiation. And only the hope that the negotiation mechanism 
> is well-understood justifies our not saying more here. Were I to 
> re-write this again, I would change the closing sentence to be:
> 
>    The UAC MUST also include the 'recipient-list-message'
>    option-tag (defined in Section 5) in a Require header field,
>    which will result in rejection of this request by any UAS
>    that does not implement this extension.
> 
> 
> Now, Miguel didn't take all my suggestions. Instead, he produced the 
> following in -07
> 
>    A UAC that wants to create a multiple-recipient MESSAGE request
>    creates a MESSAGE request that MUST be formatted according to RFC
>    3428 [8] Section 4.  The UAC populates the Request-URI with the SIP
>    or SIPS URI of the MESSAGE URI-list service.  In addition to the
>    regular instant message body, the UAC adds a URI-list body whose
>    Content-Disposition type is 'recipient-list', specified in the
>    Framework and Security Considerations for SIP URI-list Services [11].
>    This body contains a URI-list with the recipients of the MESSAGE.
>    Target URIs in this body MAY also be tagged with the 'capacity' and
>    'anonymize' attributes specified in the XML Format Extension for
>    Representing Capacity Attributes in Resource Lists [12].  The UAC
>    MUST also include the 'recipient-list-message' option-tag, defined in
>    Section 5, in a Require header field.
> 
> He still has two MUSTs that one has to dereference (but there ARE 
> references given), and a MAY (which is also referenced). All the 2119 
> language that doesn't have a real functional requirement attached to it 
> has been removed. While it's not as pretty as mine (opinion), it's at 
> least testable for compliance, and the important aspects of the 
> "required" behavior can at least be extracted from the specification.

I agree that the text is an improvement with respect version -05. And I 
want to thank you for your comments.

/Miguel

> 
> 
> -- 
> Dean
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Aki Niemi <[email-masked]>
Date: Wed, 01 Mar 2006 12:10:43 +0200

ext Dean Willis wrote:
> What's the Finnish word for idiot, anyhow? I'm sure I've overheard it in
> some of those standards discussions after I've said something
> "controversial", but it would be nice to know. One can never know too
> many insults, they're such handy words.

It's "idiootti", "idiootit" in plural.

But we never use that, because it's too close to English. Instead, we
usually exclaim "ääliö", "tollo", "taukki", "hölmöläinen", or plain
simple "tyhmä". With a smile on our face, of course.

;-)

Cheers,
Aki

---

From: "Pete Cordell" <[email-masked]>
Date: Wed, 1 Mar 2006 10:13:56 -0000

----- Original Message From: "Miguel Garcia" <[email-masked]>
> the Require header. I don't think this draft is a SIP tutorial.

I agree with Miguel here - too much tutorial material can make it harder for
the more experienced developer to read, and eventually even the beginner
will become experienced and thank you in the long run for omitting tutorial
material!  That said with all the documents that make up SIP, a little
guidance to novices would be helpful.  For that a simple reference should
suffice, along the lines of:

    ...Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field (RFC 3261
    [5] Section 8.2.2.3).

It would be even better if the referencing mechanism could be made more
specific so that you get something of the form:

    ...Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field [5:8.2.2.3].

e.g. a references ABNF becomes:

    ref = '[' doc-id [ ':' section-number ] ']'
    doc-id = 1*DIGIT
    section-number = 1*DIGIT  *( '.' 1*DIGIT )

Alternatively, you could define special references that are primarily
intended to aid novices only.  For example, you could include text of the
form:

    This document contains special references that are primarily included
    for the benefit of those new to SIP.  These special references have the
    form '{' rfc-number ':' section-number '}'.  Here the rfc-number part
    specifies an RFC, and the section number refers to the relevant section
    within the referenced RFC.  For example, {RFC3261:8.2.2.3} refers
    to the Require header in the main SIP specification.

Pete
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
                         for XML to C++ data binding visit
                         http://www.tech-know-ware.com/lmx
                         (or http://www.xml2cpp.com)
=============================================

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 1 Mar 2006 07:36:50 -0600

Falling off-topic for SIPPING, except that the SIP community seems to need 
this facility more than most...

From: "Pete Cordell" <[email-masked]>

>    option-tag, defined in Section 5, in a Require header field 

Having recently reviewed an Internet Draft with a reference that said, "see 
RFC 1122" with no indication which of the 116 excellent pages might be 
helpful, I can only agree :-)

Thanks,

Spencer

---

From: "Dale R. Worley" <[email-masked]>
Date: Wed, 01 Mar 2006 10:03:30 -0500

> simple "tyhmä". With a smile on our face, of course.

I'm glad to see that Finnish has such careful shades of meaning in this
domain.

Hmmm, it reminds me of the joke, "Just as the Eskimo language has 27
words for various types of snow, Yiddish has 100 ways to call someone an
idiot."

Perhaps this is an area in which standardization is needed?  ;-)

Dale

---

From: Dean Willis <[email-masked]>
Date: Wed, 01 Mar 2006 10:21:14 -0600

> accordingly, and wouldn't be understood by the URI-list server.

But the MUST is in the wrong place. It's not the case that the UA MUST 
create a message request. But it is true that if it does create a 
MESSAGE request intended to be compliant with this specification, then 
it MUST format the request according to RFC 3428. Your new usage (as of 
-07) makes this much clearer.

> lack of interoperability.

Since none of these alternatives are evident in the text, SHOULD doesn't 
work.

>> SHOULD #2 (add a URI-list body): Again, what are the alternatives? 
>> We're not defining any here. We're just trying to describe a use case.
> 
> 
>> MAY #1 (also include the 'capacity' extension): Why would we want to 
>> do that? Fortunately, the "why" is defined in the referenced section 
>> 4.1. But are we stating an aspect of optionality that affects 
>> interoperability? Nope. We're just describing some information that, 
>> if present in the request, will be used in processing the request at 
>> the recipient, and if it's not there, it won't be.
> 
> 

There is a difference between choices that the user may make (like 
choosing to use the capability extension schema to indicate BCC 
participants), and implementation decisions that MAY be coded into a system.

It's the difference between saying that you MUST drive to Madrid (when 
all you've done is decide to drive there and nobody is threatening your 
life if you don't), and saying that if you drive to Madrid, you MUST NOT 
exceed the national speed limit of 90 kph or you are subject to being 
fined or arrested.

...

> with a URI-list server implemented according to this specification. Got it?

Huh? An MSRP SEND request is not a MESSAGE request as per RFC 3428 
section 4.

. . .

> fail to reach the URI-list server.

I think we're failing to communicate at a fundamental level here.

For example, you might reach the URI-list server by populating the 
request with another URI that is translated by a proxy into the request 
URI of the URI-list server. Would this be a violation of the protocol 
almost certain to cause an interoperability problem? Would it be a 
violation of the protocol at all? If not, WHY IS IT WRITTEN AS A 
REQUIREMENT?

. . .

> want to thank you for your comments.

And I want to thank you for listening to them. And of course for letting 
me use your material as an example in this discussion abd being a good 
sport about it.

--
dean

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 02 Mar 2006 12:52:36 +0200

Some more comments inline.

Dean Willis wrote:
>> It is true that we are not defining the alternatives, although a few 
>> of them exists: the list is already pre-stored in the URI-list server, 
>> or it is pointed by some content indirection.
>>
>>>
>> I think this MAY is drafted according to the definition of "MAY" in 
>> RFC 2119:
>>

At least the intention is to indicate that the URI-list list have to 
implement this option, but it is at the discretion of the UAC to use it 
or not.

>> to this specification, even when such UAC won't be able to 
>> interoperate with a URI-list server implemented according to this 
>> specification. Got it?
> 

Exactly, I was indicate an extreme weird use case to illustrate why, in 
this service, the UAC MUST create a MESSAGE request according RFC 3428 
Section 4. It is not enough to say that the UAC creates a MESSAGE 
request, because then we don't have normative text indicating that the 
MESSAGE URI-list service is implemented with MESSAGE request, not by 
other means such as the absurd one I invented above.

>> Another problem. This is an instance description. But if you have a 
>> UAC that populates the Request-URI with something else, the 
>> consequence (unless you really really thought about them) is that the 
>> request will fail to reach the URI-list server.
> 

I can agree with you that routability failures should be separated from 
protocol violations. The aim of the text was to avoid a routability 
failure rather than a protocol violation, so I can buy your argument 
that this shouldn't be written as a requirement. Note that this is 
already fixed in version -07 of the draft.

/Miguel

> 
> . . .
> 
>> I agree that the text is an improvement with respect version -05. And 
>> I want to thank you for your comments.
>