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

From: "Chris Boulton" <[email-masked]>
Date: Thu, 15 Apr 2004 10:44:24 +0100

OK - I will change the text and remove the references to offer/answer
negotiation.

Thanks for the input,

Regards,

Chris.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: 15 April 2004 09:36
>To: [email-masked]; Chris Boulton
>Cc: [email-masked]
>Subject: RE: [Simple] message-sessions-05
>
>Paul is right. There is no point in negotiating. The recipient may
either
>choose a receipt type from the list as offered by the sender, or it can
use
>the default (if it chooses not to honour the sender's preferred receipt
>types). The sender MUST be prepared to receive receipts in the default
>format as well as all the formats it offered.
>
>Thanks,
>Hisham
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]On Behalf
Of
>> ext Paul Kyzivat
>> Sent: 14.April.2004 18:27
>> To: Chris Boulton
>> Cc: Simple WG
>> Subject: Re: [Simple] message-sessions-05
>>
>>
>> Chris Boulton wrote:
>> >>
>> >>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.
>> >
>> > [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.
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> Simple mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/simple
>>

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

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