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

From: [email-masked]
Date: Thu, 15 Apr 2004 11:36:18 +0300

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
> 

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