Subject: RE: [Simple] message-sessions-05

From: "Chris Boulton" <[email-masked]>
Date: Wed, 14 Apr 2004 15:56:16 +0100

>
>Chris Boulton wrote:
>> Paul,
>> 	That was the intention the intention from
>>
>> An MSRP endpoint MUST be capable of performing the DSN
>>    operations described in this specification and SHOULD support the
DSN
>>    MIME type outlined.
>>
>> Perhaps I could make this more explicit and add text to specify that
>> even if an alternative is specified in the receipt request, a client
>> SHOULD be able to receive the default receipt type.
>
>OK. If we are agreed on that, then what is the value of negotiating
>alternative receipt types in the offer/answer? Just indicate your
>preferred optional type in the message. The recipient will honor it if
>it can and wants to, or else it will use the default type. You have to
>be prepared to accept the default type anyway, so nothing is gained by
>an earlier negotiation.
>
>	Paul

[Chris Boulton] The idea was that an alternative mechanism CAN be used
BUT it MUST be listed as a supported type that appeared in the
offer/answer exchange - there could be many supported types listed.
This increases the likelihood that the alternative payload is supported
by both clients.  This does not override the default BUT enhances the
options available on a per message basis and makes it far more
extensible. 

>
>>>-----Original Message-----
>>>From: Paul Kyzivat [mailto:[email-masked]]
>>>Sent: 14 April 2004 14:38
>>>To: Chris Boulton
>>>Cc: Simple WG
>>>Subject: Re: [Simple] message-sessions-05
>>>
>>>
>>>
>>>Chris Boulton wrote:
>>>
>>>>>Receipt-Type negotiation: Seems bad to have to accept a receipt as
a
>>>>>regular message in order to negotiate it as an alternate receipt
>>>>
>> type.
>>
>>>>>Seems better to just let receipt-type be a request for a different
>>>>
>> type
>>
>>>>>that can be honored or not, with the default type being always
>>>>>acceptable.
>>>>
>>>>[Chris Boulton] mmmmm - not convinced.  Doesn't this all depend on
>>>
>> the
>>
>>>>importance placed on receiving the receipt?  It could be critical
for
>>>
>> me
>>
>>>>to know it has been delivered.  If an alternative receipt type is
>>>>specified it must be one that was specified in the offer-answer
>>>>exchange.  If, for some reason the far end can not create the
receipt
>>>>due to this type, it should kick back with an appropriate error
>>>>response.  If a relay was involved, it could generate a negative
>>>
>> receipt
>>
>>>>on the endpoints behalf.
>>>
>>>Actually, the possible involvement of a relay supports my argument.
It
>>>doesn't get to participate in the media type negotiation, yet it may
>>>have to generate a negative receipt. And it may only be able to
>>
>> generate
>>
>>>the default receipt type.
>>>
>>>So, the sender of a message that requests a receipt must be prepared
to
>>>accept a receipt of the default type even if it would prefer some
other
>>>type.
>>>
>>>	Paul
>>
>>
>>
>>
>> This message has been scanned for viruses by MailControl -
>www.mailcontrol.com
>>

This message has been scanned for viruses by MailControl - www.mailcontrol.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple