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

[Miguel Garcia <[e-mail]>]

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".

> Old:
> 
>    The MESSAGE
>    URI-list service can include a resource list in the outgoing MESSAGE
>    request that contain those resources tagged with a To or Cc
>    capacities (and not Bcc capacities). This allows the creator of the
>    incoming MESSAGE request to identify if a resource should be
>    receiving a copy of the MESSAGE request as a capacity of recipient
>    (to), carbon copy (cc) or blind carbon copy (bcc).  It also allows
>    some the intended recipients to reply to the initial sender and all
>    the visible recipients of the MESSAGE request.
> 
> New:
> 
> The MESSAGE URI-list mechanism allows a sender to specify multiple 
> targets for a MESSAGE request by including a resource list in the body 
> of the MESSAGE request. This resource list includes the URIs of the 
> targets. Each target URI may also be marked to indicate in what capacity 
> (or role) the URI-list service will place the target. The available 
> capacities include "to", "cc", and "bcc".  When the MESSAGE URI-list 
> server expands the request for each recipient, it includes a new 
> URI-list that contains only the targets originally listed in "to" and 
> "cc" capacities, and excludes those listed in the "bcc" capacity. This 
> allows recipients to both see and reply to the "to" and "cc" targets, 
> but not to the "bcc" targets. The default capacity assumed if one is not 
> specified by the sender is "to". This is discussed in greater detail in 
> section 4.1 of this document.
> 
> 
> Note: Section 4.1 says the capacity tag should be included, but doesn't 
> say what happens if it isn't. It needs to a say this (I presume an 
> unspecified recipient is "to").
> 

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".
> 
> 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.


> 
> 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.


> 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.

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.

> 
> 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.

> 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.

> 
> 
> A note for final publication readiness readiness: Section 13 contains 
> series of "Changes since"  paragraphs that need to be deleted. We should 
> delete these before sending the final doc to the IESG. The only 
> exception to this might be a document that is obsoleting another RFC, 
> and that contains a discussion of changes relative to the RFC being 
> obsoleted.
> 

OK.


> -- 
> Dean
> 
> 
> 

Thanks for the review.

/Miguel


> _______________________________________________
> 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
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP