Re: [Sipping] Pre pub-request feedback on draft-ietf-sipping-uri-list-message-05

[Dean Willis <[e-mail]>]

On Jan 26, 2006, at 10:38 AM, Miguel Garcia wrote:

> Hi Dean:
>
> Thanks for the review. I agree with most of your issues, thus, I  
> don't reproduce them here. But some of them require a bit more of  
> discussion. Please take a look at those issues below:
>
>
> Dean Willis wrote:
>
>> In Section 3, Overview
>> What does "to" or "from" have to do with "capacity"? Most people  
>> think of capacity as "how much will it hold", like 5 liters or 200  
>> kilograms or 37 recipients. The term is first used in the  
>> overview, section 3, paragraph 3. Perhaps a breakout defining  
>> capacity in thus usage would help. There are also some "s" missing  
>> on the end of words, like "contains". We also don't say what  
>> happens if the "capacity" is unspecified.
>
> Ok, I agree with the proposed new text. We need to evaluate if we  
> can introduce the "capacity" attribute concept earlier in the  
> document.
>
> One point of disagreement is the default capacity attribute, which  
> set to be "bcc". That is already described in Section 4.1. I agree  
> we need to indicate this also in Section 3, but it is to be set to  
> "bcc".
>

Setting to bcc is fine with me, as long as the default gets mentioned  
where the concept is introduced. I clearly missed it later in the  
text, so the average reader (I'm flattering myself by claiming to be  
average) is likely to suffer the confusion.

>
> As indicated before, Section 4.1 says:
>
> The default 'capacity' value is "bcc", that is, the absence of a  
> 'capacity' attribute MUST be treated as if the 'capacity' was set  
> to "bcc".
>>

Spiffy.


>> Question: Did anybody formally validate the schema and XML doc in  
>> the example? I'm not an XML guy. Somebody please tell me you've  
>> validated it.
>>
>
> Yes, I validated the schema with XMLSpy and it is valid.
>
> However, I also validated with the validator at http:// 
> validate.openlaboratory.net/ and it complains about the Unique  
> Particle Attribution rule of the resource-list XML Schema (not  
> about the MESSAGE exploder draft itself).  The issue has been  
> discussed in the SIMPLE mailing list, see http://www.ietf.org/mail- 
> archive/web/simple/current/msg05954.html
> Unfortunately, there is nothing I can do to solve this problem,  
> since there is nothing wrong in the XML Schema or the example in  
> this draft.

Hmm. That's supposedly the validator we'll be tested against. Jari  
should know about it . . .

in fact, he said:

"Good catch, yes this schema violates the infamous Unique Particle
Attribution (UPA) constraint (well yet another example that we should
switch using RELAX NG ;-)). It is not about recursion it is about
overlapping wildcards. So the first definition should be removed. Also
there are some processContents="lax" definitions that seem to be
missing, 48hours ?"

so perhaps Jari can now help us figure out what needs to be done.

HELP! Please?

>
>
>> The procedures text in Section 6 uses 2119 language  
>> inappropriately, I think.  This is somewhat subjective, but I  
>> prefer not to use requirements language to describe what something  
>> just does. It should be reserved for places where we're actually  
>> discussing requirements, quoting requirements imposed by other  
>> specifications, and  giving specific guidance on what might  
>> otherwise seem reasonable behavior but will break compatibility  
>> with other systems or elements.
>
>
> Careful here, some of the suggestions make sense, others not.  
> Remember that this are Sections 6, and 7, which are the main  
> normative text of the specification. So this is not an overview or  
> general description.
>

I'd like to point out Section 6 of 2119, which says:

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability

We have historically habitually overused this language to describe  
basic operating methodology, which I believe conflicts with the  
specifics of the above-quoted section.

>
>> For example:
>> Section 6: Procedures  at the User Agent Client
>> Old:
>>    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.
>> I would suggest writing as:
>> New:
>>    A UAC that wants to create a multiple-recipient MESSAGE request
>>    creates a MESSAGE request 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', 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.
>> Not every "does" is a "MUST", and not every "might do" is a MAY.   
>> We're just talking about how something works, not defining  
>> requirements or calling out critical interop characteristics. The  
>> final MUST is there because if the UA doesn't do this, it violates  
>> the feature negotiation rules of SIP.
>
> I disagree. I think it is essential for the protocol to work that  
> the sender MUST follow the procedures of RFC 3824 Section 4. It is  
> a MUST, otherwise, this does not work.

Well, there are different theories about 2119-language usage. Clearly  
if the UAC does not create a MESSAGE request, it doesn't create a  
MESSAGE request intended for multiple recipients. But describing what  
something does is not the same thing as requiring what it MUST do.  
For example, the implications of a MUST are that we need to explain  
why it is a MUST and what the consequences of not doing it are, or  
refer to another document that contains that elucidation.

> I also think the MESSAGE request SHOULD contain a URI-list (it  
> could contain any other format if "you really know what you are  
> doing"). The URI list MAY contain a capacity attribute. This is  
> something that we see in the wire, and it MAY be present at the  
> sender's discretion.

But all we're documenting here is a URI-list. So it MIGHT do  
anything, and what we're really saying here is that an implementation  
that supports this specification contains a URI-list. If it contains  
something else, we have nothing here to say about what happens. Why  
SHOULD this request contain a URI-list? If we don't discuss this,  
we're simply saying what it does, not raising a critical point of  
operation worthy of 2119 language.

>> A subsequent paragraph raises similar concerns:
>> Old:
>>    Typically, the MESSAGE URI-list service will copy all the  
>> significant
>>    header fields in the outgoing MESSAGE request.  However, there  
>> might
>>    be cases where the SIP UA wants the MESSAGE URI-list service to  
>> add a
>>    particular header field with a particular value, even if the  
>> header
>>    field wasn't present in the MESSAGE request sent by the UAC.   
>> In this
>>    case, the UAC MAY use the "?" mechanism described in Section  
>> 19.1.1
>>    of RFC 3261 [5] to encode extra information in any URI in the  
>> list.
>>    However, the UAC MUST NOT use the special "body" hname (see  
>> Section
>>    19.1.1 of RFC 3261 [5]) to encode a body, since the body is  
>> present
>>    in the MESSAGE request itself.
>> New:
>>    Typically, the MESSAGE URI-list service will copy all the  
>> significant
>>    header fields in the outgoing MESSAGE request.  However, there  
>> might
>>    be cases where the SIP UA wants the MESSAGE URI-list service to  
>> add a
>>    particular header field with a particular value, even if the  
>> header
>>    field wasn't present in the MESSAGE request sent by the UAC.   
>> In this
>>    case, the UAC may use the "?" mechanism described in Section  
>> 19.1.1
>>    of RFC 3261 [5] to encode extra information in any URI in the  
>> list.
>>    However, the UAC MUST NOT use the special "body" hname (see  
>> Section
>>    19.1.1 of RFC 3261 [5]) to encode a body, since the body is  
>> present
>>    in the MESSAGE request itself.
>
> I think I disagree: the UAC MAY use the "?" mechanism, it is an  
> option for the UAC to either use it or not. At least, according to  
> my reading, it falls into Section 5 of RFC 2119.

That's possibly supportable. Clearly the MUST NOT above is good, as  
it raises a critical point of interop, and explains WHY that MUST NOT  
applies. But the MAY is in a "Typically" section, so again, we're  
talking a description of how something works, which is not the same  
thing as operational requirements.


>
>> Similarly in 7.1 Determining the Intended Recipient:
>> Old:
>>    On reception of a MESSAGE request with a URI-list, a MESSAGE  
>> URI-list
>>    service SHOULD determine the list of intended recipients, by
>>    inspecting the URI-list contained in the body.  In case two of  
>> those
>>    URIs are equivalent (section 19.1.4 of RFC 3261 [5] defines
>>    equivalent URIs), the MESSAGE URI-list SHOULD consider a single
>>    intended recipient.
>> New:
>>    On reception of a MESSAGE request with a URI-list, a MESSAGE  
>> URI-list
>>    service determines the list of intended recipients, by
>>    inspecting the URI-list contained in the body.  In case two of  
>> those
>>    URIs are equivalent (section 19.1.4 of RFC 3261 [5] defines
>>    equivalent URIs), the MESSAGE URI-list SHOULD consider this to
>>    represent a single intended recipient rather than sending multiple
>>    copies of the MESSAGE to the same destination.
>
> OK, I agree with the above change.
>
>> In 7.2 Creating an Outgoing Message Request
>> Old;
>>    o  A MESSAGE URI-list service MUST include a From header field  
>> whose
>>       value is the same as the From header field included in the
>>       incoming MESSAGE request, subject to the privacy  
>> requirements (see
>>       RFC 3323 [6] and RFC 3325 [7]) expressed in the incoming  
>> MESSAGE
>>       request.  Note that this does not apply to the "tag" parameter.
>>    o  A MESSAGE URI-list service SHOULD generate a new To header  
>> field
>>       value set to the intended recipient URI.  According to the
>>       procedures of RFC 3261 Section 8.1.1.1, this value should  
>> also be
>>       equal to the Request-URI of the outgoing MESSAGE request.
>>    o  A MESSAGE URI-list service SHOULD create a new Call-ID header
>>       field value.
>> New:
>>    o  A MESSAGE URI-list service includes a From header field whose
>>       value is the same as the From header field included in the
>>       incoming MESSAGE request, subject to the privacy  
>> requirements (see
>>       RFC 3323 [6] and RFC 3325 [7]) expressed in the incoming  
>> MESSAGE
>>       request.  Note that this does not apply to the "tag" parameter.
>>    o  A MESSAGE URI-list service generates a new To header field
>>       value set to the intended recipient's URI.  According to the
>>       procedures of RFC 3261 Section 8.1.1.1, this value SHOULD  
>> also be
>>       equal to the Request-URI of the outgoing MESSAGE request.
>>    o  A MESSAGE URI-list service MUST create a new Call-ID header
>>       field value, as per the procedures of RFC 3261 section 8.1.1.4.
>
> I can't agree with the above. This is the normative part that  
> indicates how the MESSAGE URI-list service must populate the From,  
> To, and Call-ID. Without this normative specification we will not  
> have a deterministic way of populating these headers.
>

I'm willing to agree in principle, but suggest that we should follow  
up by explaining the normativity. Why, for example, is a message  
exploder that is also an anonymizer or reattributor in violation of  
this specification? What does that do to prevent the possibility of  
interoperability?

--
Dean


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