Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
RFC 5363

Note: This ballot was opened for revision 07 and is now closed.

(Jon Peterson) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lars Eggert) (was Discuss) No Objection

(Pasi Eronen) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

Comment (2008-06-30)
No email
send info
>   recipients as the ones specified by the client).  To prevent this
>   attack, clients SHOULD integrity protect URI lists using mechanisms
>   such as S/MIME, which can also provide URI-list confidentiality if
>   needed.

Given I've never seen S/MIME deploy outside limited enclaves, I question
if this mitigation will actually deploy on Internet scale.  Can you
suggest an alternative mitigation option that may not be as strong as
S/MIME, but might actually be deployable (e.g., hop-to-hop TLS/DTLS,
leap-of-faith keying similar to SSH, etc)?

I find it both misleading and distasteful to use "SHOULD" when it's
something that's likely to remain unimplemented or rarely deployed.

I do not view this issue as a barrier to proposed status, but it would
be a barrier to future advancement so it might be better to be realistic
now.

>            recipient-list    the body contains a list of URIs

This is unclear and misleading for a "disposition".  A disposition
should describe how the content is used, while the media type should
describe what's in the content.  This should be easy to fix.

I suggest instead
            recipient-list    process as URI list

A more verbose description would be:

The "recipient-list" disposition results in a conversion of the body's
content-type to an abstract list of URIs which are then processed by the
service.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection