Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services
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
> 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.