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

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

>-----Original Message-----
>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: 14 April 2004 16: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
>
[Chris Boulton] Paul - I'm not disagreeing with you - this is good
stuff.  I was just trying to offer a mechanism where by a strong hint of
supported types was agreed + increasing the likelihood that the far end
will support the type that I have explicitly specified on a per MSRP
transaction basis - rather than just a hit and hope.

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

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