I cannot argue with that position :-) +1 On Sep 16, 2008, at 9:24 PM, Hisham Khartabil wrote:
For the sake of moving this draft to completion, I plan to remove the <note> element from IMDNs. If someone is interested in extending the schema to allow an element that carries extra information about the reasons behind a certain disposition status, please write an I-D.Any objections? Regards, Hisham On 04/06/2008, Eric Burger <eburger at standardstrack.com> wrote: Except:1. I have no clue what language to use in the message, as a human will read it.2. The field is free-form, so is not amenable for automaton processing.3. The field is free-form, but could be read by the UAC, so it will invite vendors to put proprietary information into the field. Then users expect particular behaviors when these values are present. I.e., who needs the IETF to review protocol element use? Let the random implementor of the day build a protocol on top of IMDN!4. The field is free-form and displayed to the user, so it will invite spam.If it is useful from a protocol perspective, then create an IANA registry of values.On Jun 4, 2008, at 5:19 AM, Hisham Khartabil wrote: The field is not useless. It carries extra information (a reason phrase, if you like) as to why the IM delivery resulted in an error or still being processed, etc. Hisham 2008/6/4 Ben Campbell <ben at estacado.net>: On May 23, 2008, at 2:21 PM, Eric Burger wrote: Actually, IMDNs, even the SIMPLE free-form fields, are fairly constrained. Any mis-match is an opportunity to filter out bad IMDNs. The <note> field has three problems: 1. It cannot be filtered, as any content could be real (which introduces the attack vector) 2. It cannot know what language it should use, and thus is not likely to be useful to the recipient 3. It has no protocol value, and is of no value to the UA So, if something has no useful protocol value and introduces a spam opportunity, why would we want to include it? If something has no useful protocol value, even if it _does_no_harm, why would we want to include it? IMHO, there is no need to prove a vector for harm, if we are fairly certain there is no vector for _utility_. (Note that I am agnostic on whether the field is truly useless--I am merely commenting on the form of the argument.) On May 21, 2008, at 7:45 PM, Paul Kyzivat wrote: Its kind of late to be thinking about this now. THe problem is pervasive in MSRP. In SIP there are lots of unconstrained fields. But they are all constrained by the overall size of the message, and people commonly put limits on that. In MSRP, because of chunking, a single MSRP message can be gigabytes long. So using that to bound the unconstrained parts of the headers doesn't work very well. A robust implementation might take a similar approach - define its own limit on the total message size, excluding the body. Then it could constrain all the unconstrained fields to fit within it. But picking on one header isn't a solution to the problem. Either assume the developers will be able to deal with it, or else do and MSRPv2 that eliminates all unconstrained fields. Paul Dean Willis wrote: On May 13, 2008, at 11:38 PM, Hisham Khartabil wrote: Can you explain how it is an attack vector? Unconstrained rich content is one of the most easily exploited attack vectors. Buffer overrun attacks as well as all of the typical MIME compound- component attacks are likely. For example, the common JPEG vulnerabilities might be exploitable: http://www.news.com/Image-virus-spreads-via-chat/2100-7349_3-5390463.html Or the content-execution weakness that caused the Macintosh Safari browse to be most easily exploited in recent hacking contests: http://www.engadget.com/2007/07/23/safari-exploit-gives-hackers-full-control-of-your-iphone/ There have also been exploits against QuickTime, Flash, and most other plugin components from time to time. -- Dean _______________________________________________ Simple mailing list Simple at ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple at ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple at ietf.org https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple at ietf.org https://www.ietf.org/mailman/listinfo/simple
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Simple mailing list Simple at ietf.org https://www.ietf.org/mailman/listinfo/simple