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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Apr 2004 11:27:14 -0400

> options available on a per message basis and makes it far more

I don't see how this enhances the options available on a per-message 
basis. I can request a particular type even if it hasn't been 
negotiated. And whether it has been negotiated or not, I may receive 
what I request or not.

I think maybe we need a concrete use case here. I'm just making this up 
- it seems plausible, though I don't know if it is realistic:

Lets assume I want to transfer a file over this msrp session. Maybe for 
file transfers there is extra information that is worth reporting back. 
(Whether the file could be stored in the file system, or whatever.)

So to support this there are a pair of content types:

	application/file (wraps the mimetype of the file)
	application/file-transfer-report (the alternative report format)

Conceivably I might like the UI of my application to only offer file 
transfer if I know I will get a file transfer report back.

Following your proposal, I could negotiate both content types as part of 
the offer/answer, and disable file transfer in my UI if they aren't both 
accepted. But does that let me achieve what I want? No! The following 
bad things can happen:

- I can send the file. The other end, while in some sense supporting
   the file-transfer-report format, decides not to use it in reporting
   the result. This might happen because it has a generic plugin
   mechanism for content types, and there is one installed that
   understands the type, but the receiving application doesn't know
   how to use that type in this context. So I get the default report.

- I could start receiving file-transfer-reports as send message bodies.
   But I only know how to deal with them as reports, not as messages.

The point is that supporting a type isn't an all or nothing thing. The 
type is supported for certain purposes. Exchanging as messages is one 
purpose. Exchanging as delivery reports is a different purpose. If you 
want to negotiate this, then the negotiation needs to include the usage 
context. Certainly we could introduce a separate a-line to be used for 
negotiating delivery report types. But I just don't see the value in 
doing so.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Apr 2004 11:27:14 -0400

Paul