Re: [Simple] <note> in IMDN

["Hisham Khartabil" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>:
>>
>>>
>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>>>
>>>>>> _______________________________________________
>>>>> Simple mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>>
>>>>
>>>> _______________________________________________
>>>> Simple mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/simple
>>>>
>>>
>>> _______________________________________________
>>> Simple mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/simple
>>>
>>>
>

_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple