Subject: [Simple] Chat: questions on 'accept-wrapped-types'

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 11 Sep 2012 14:46:23 +0200

Hi,

the chat draft uses the 'accept-wrapped-types' in SDP for negotiating a 
minimum set of supported types inside the Message/CPIM wrappers.

While I was replying to Stephen Farrell's IESG review, he had a question, 
and that one brought me another one. I am seeking advice as for how to 
proceed.

So, here are the questions:

1) Version -16 of the draft is a bit silent with respect 
'accept-wrapped-types. I first proposed these two paragraphs to be added 
to version -17, however, I have concerns with one of them (see below).

    It is RECOMMENDED that participant endpoints
    add an 'accept-wrapped-types' attribute to the MSRP 'message' media
    line in SDP, where the supported wrapped types are declared, as per
    RFC 4975 procedures [RFC4975].

    The conference focus SHOULD also add an 'accept-wrapped-types'
    attribute to the MSRP message media line in SDP containing the
    supported wrapped types.

My question is... does the conference focus need to add an 
'accept-wrapped-types'? The MSRP switch never interprets the actual 
payload contents, so, for the MSRP switch, the actual payload in instant 
messages is transparent. So, why should the MSRP switch care? Why should 
the focus add an 'accept-wrapped-types' at all?

I propose to replace the initially proposed "SHOULD" with a "MAY" in the 
previous paragraph.

2) Stephen Farrel is questioning what should the MSRP switch do if one 
sender sends an instant message to the chat room, the message containing 
a type (inside Message/CPIM) that not all the recipients can understand. 
In other words, the MSRP switch/focus has received SDP indicating that an 
endpoint supports types A, B, and C. If another participant sends a 
message with type D, what should the MSRP switch do?

Possibilities include:
a) Do nothing; forward the message to D, he should deal with the issue. I 
don't like this, because it is bypassing the MSRP accept-* negotiation.

b) Do not forward the message to this user, but forward to others who 
accept this type. It is possible that the MSRP switch injects a warning 
instant message to the sender, indicating this condition.

c) Reject the message to the sender (i.e., do not forward to any user). I 
don't like this option either, because the poor sender has done nothing 
wrong. Additionally, this is the dictatorship of the minority (a few 
people who do not support a type that will be supported by the majority 
will impose their rules). And it will be so easy to kill a chat room by 
just logging in supporting only weird type that none else supports.

So, probably b) is the less worst of all. Comments?

I also want to highlight that this is a bit theoretical problem. I expect 
most implementations to support all commonly known types. Additionally, I 
expect implementations to add a "*" to indicate support for additional 
types that have not been explicitly listed, in which case, the MSRP 
switch will not do any filter, and it is about the endpoint to render the 
content or not.

Comments?

BR,

          Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Sep 2012 09:23:58 -0500

On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" <[email-masked]> wrote:

> Hi,
> 
> the chat draft uses the 'accept-wrapped-types' in SDP for negotiating a minimum set of supported types inside the Message/CPIM wrappers.
> 
> While I was replying to Stephen Farrell's IESG review, he had a question, and that one brought me another one. I am seeking advice as for how to proceed.
> 
> 1) Version -16 of the draft is a bit silent with respect 'accept-wrapped-types. I first proposed these two paragraphs to be added to version -17, however, I have concerns with one of them (see below).
> 
> My question is... does the conference focus need to add an 'accept-wrapped-types'? The MSRP switch never interprets the actual payload contents, so, for the MSRP switch, the actual payload in instant messages is transparent. So, why should the MSRP switch care? Why should the focus add an 'accept-wrapped-types' at all?
> 
> I propose to replace the initially proposed "SHOULD" with a "MAY" in the previous paragraph.

I concur. It could use this to express policy about what types it allows, but it could just set it to "*" if it doesn't care.

Do we need to talk about what happens if a _recipient_ does not support a type? I suppose the focus could set accept-wrapped-types based on what all the participants have expressed--but that sounds like a recipe for re-invite storms. The focus could send a 415 response to any type where it knows that that one or more recipients cannot accept it.

> 
> 
> 2) Stephen Farrel is questioning what should the MSRP switch do if one sender sends an instant message to the chat room, the message containing a type (inside Message/CPIM) that not all the recipients can understand. In other words, the MSRP switch/focus has received SDP indicating that an endpoint supports types A, B, and C. If another participant sends a message with type D, what should the MSRP switch do?
> 
> Possibilities include:
> a) Do nothing; forward the message to D, he should deal with the issue. I don't like this, because it is bypassing the MSRP accept-* negotiation.
> 
> b) Do not forward the message to this user, but forward to others who accept this type. It is possible that the MSRP switch injects a warning instant message to the sender, indicating this condition.
> 
> c) Reject the message to the sender (i.e., do not forward to any user). I don't like this option either, because the poor sender has done nothing wrong. Additionally, this is the dictatorship of the minority (a few people who do not support a type that will be supported by the majority will impose their rules). And it will be so easy to kill a chat room by just logging in supporting only weird type that none else supports.
> 

See my previous comment.

I'm on the fence between B and C. It seems like the undetermined state of "some recipients got it but others didn't" is one of the worst outcomes. I'm not sure I agree about the DoS issue--If a participant wants to screw with the conference, there's lots of other ways he can do so. 

Another option would be to push a warning to the recipient saying that the someone had sent a type that he had not expressed support for.

> I also want to highlight that this is a bit theoretical problem. I expect most implementations to support all commonly known types.

If necessary, we could mandate a must-support leaf type (but I'm not sure if I want to go there.)

> Additionally, I expect implementations to add a "*" to indicate support for additional types that have not been explicitly listed, in which case, the MSRP switch will not do any filter, and it is about the endpoint to render the content or not.

What happens if the recipient sends a 415 response? I guess it's like any other error. That means the sender doesn't learn about it unless the switch synthesis some sort of warning, right?

I also wonder if switches and/or chat participants should be a little less generous about what types they accept in a chat. Otherwise, this starts to look like a file transfer exploder :-)

> 
> Comments?
> 
> BR,
> 
>         Miguel
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2012 11:32:51 -0400

> I concur. It could use this to express policy about what types it allows, but it could just set it to "*" if it doesn't care.

+1

> Do we need to talk about what happens if a _recipient_ does not support a type? I suppose the focus could set accept-wrapped-types based on what all the participants have expressed--but that sounds…

Isn't that what is discussed below?

> I'm on the fence between B and C. It seems like the undetermined state of "some recipients got it but others didn't" is one of the worst outcomes. I'm not sure I agree about the DoS issue--If a par…

I prefer B to C. Otherwise you have given each endpoint a veto over what 
can be exchanged. In the extreme, one endpoint could indicate it doesn't 
support either plain text or html and effectively shut down the chatroom.

It is however unpleasant for the sender not to know that some recipients 
didn't get his message.

Perhaps the focus could send a message back to the sender indicating 
that some recipients couldn't receive his message. But this could get 
tiresome if you get this for every message you send. And it's hard to 
decide on what the message type and content should be. I think it is 
better to leave this as an implementation issue rather than a standards 
issue.

> Another option would be to push a warning to the recipient saying that the someone had sent a type that he had not expressed support for.

This has the same issues as sending a message back to the sender. And I 
think I prefer the same solution - leave it as an implementation issue.

Perhaps for both, the draft can carry a note to implementers that they 
might want to consider this.

> If necessary, we could mandate a must-support leaf type (but I'm not sure if I want to go there.)

I guess if anything it would be text/plain. But that might exclude 
certain specialized conferences where the messages are consumed by 
automata rather than displayed. (E.g. game systems.)

Again I think it is sufficient as an implementation issue.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Sep 2012 11:06:24 -0500

> Isn't that what is discussed below?

Yep, reading linearly :-)

> I prefer B to C. Otherwise you have given each endpoint a veto over what can be exchanged. In the extreme, one endpoint could indicate it doesn't support either plain text or html and effectively shut down the chatroom.
> 
> It is however unpleasant for the sender not to know that some recipients didn't get his message.
> 
> Perhaps the focus could send a message back to the sender indicating that some recipients couldn't receive his message. But this could get tiresome if you get this for every message you send. And it's hard to decide on what the message type and content should be. I think it is better to leave this as an implementation issue rather than a standards issue.
> 
> This has the same issues as sending a message back to the sender. And I think I prefer the same solution - leave it as an implementation issue.
> 
> Perhaps for both, the draft can carry a note to implementers that they might want to consider this.

I can live with that.

> I guess if anything it would be text/plain. But that might exclude certain specialized conferences where the messages are consumed by automata rather than displayed. (E.g. game systems.)
>

---

From: "Eric Burger"<[email-masked]>
Date: Tue, 11 Sep 2012 13:17:11 -0500

We solved the three-out-of-four endpoints understand D problem years ago.  
See RFC 3459. UAC's mark the message as critical (gets rejected if unable to  
send to all recipients) or not critical (gets silently dropped or  
destination gets a notice).

--
Sent from my mobile device. Thanks be to lemonade!  
http://www.standardstrack.com/ietf/lemonade/

-----Original message-----
From: Paul Kyzivat <[email-masked]>
To: [email-masked]
Sent: Tue, Sep 11, 2012 15:33:00 GMT+00:00
Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types'

>> 1) Version -16 of the draft is a bit silent with respect  
'accept-wrapped-types. I first proposed these two paragraphs to be added to  
version -17, however, I have concerns with one of them (see below).
>> My question is... does the conference focus need to add an  
'accept-wrapped-types'? The MSRP switch never interprets the actual payload  
contents, so, for the MSRP switch, the actual payload in instant messages is  
transparent. So, why should the MSRP switch care? Why should the focus add  
an 'accept-wrapped-types' at all?
previous paragraph.
>
> I concur. It could use this to express policy about what types it allows,  
but it could just set it to "*" if it doesn't care.

+1

> Do we need to talk about what happens if a _recipient_ does not support a  
type? I suppose the focus could set accept-wrapped-types based on what all  
the participants have expressed--but that sounds like a recipe for re-invite  
storms. The focus could send a 415 response to any type where it knows that  
that one or more recipients cannot accept it.

>> 2) Stephen Farrel is questioning what should the MSRP switch do if one  
sender sends an instant message to the chat room, the message containing a  
type (inside Message/CPIM) that not all the recipients can understand. In  
other words, the MSRP switch/focus has received SDP indicating that an  
endpoint supports types A, B, and C. If another participant sends a message  
with type D, what should the MSRP switch do?
don't like this option either, because the poor sender has done nothing  
wrong. Additionally, this is the dictatorship of the minority (a few people  
who do not support a type that will be supported by the majority will impose  
their rules). And it will be so easy to kill a chat room by just logging in  
supporting only weird type that none else supports.
> I'm on the fence between B and C. It seems like the undetermined state of  
"some recipients got it but others didn't" is one of the worst outcomes. I'm  
not sure I agree about the DoS issue--If a participant wants to screw with  
the conference, there's lots of other ways he can do so.

> Another option would be to push a warning to the recipient saying that the  
someone had sent a type that he had not expressed support for.

>> I also want to highlight that this is a bit theoretical problem. I expect  
most implementations to support all commonly known types.

	Thanks,
	Paul

>> Additionally, I expect implementations to add a "*" to indicate support  
for additional types that have not been explicitly listed, in which case,  
the MSRP switch will not do any filter, and it is about the endpoint to  
render the content or not.
>
> What happens if the recipient sends a 415 response? I guess it's like any  
other error. That means the sender doesn't learn about it unless the switch  
synthesis some sort of warning, right?
>
> I also wonder if switches and/or chat participants should be a little less  
generous about what types they accept in a chat. Otherwise, this starts to  
look like a file transfer exploder :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2012 14:34:55 -0400

On 9/11/12 2:17 PM, Eric Burger wrote:
> We solved the three-out-of-four endpoints understand D problem years
> ago. See RFC 3459. UAC's mark the message as critical (gets rejected if
> unable to send to all recipients) or not critical (gets silently dropped
> or destination gets a notice).

Good point.

So you are suggesting we assume the use of the Content-Disposition 
header in the CPIM wrapper? And the default is REQUIRED, so the focus 
should reject the message if it can't be delivered to all recipients and 
it *doesn't* contain a c-d of OPTIONAL?

That WFM.

	Thanks,
	Paul

>     *From: *Paul Kyzivat <[email-masked]>*
>     To: [email-masked]*
>     Sent: *Tue, Sep 11, 2012 15:33:00 GMT+00:00*
>     Subject: *Re: [Simple] Chat: questions on 'accept-wrapped-types'
>
>      > On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" wrote:
>      >
>      >> Hi,
>      >>
>      >> the chat draft uses the 'accept-wrapped-types' in SDP for
>     negotiating a minimum set of supported types inside the Message/CPIM
>     wrappers.
>      >>
>      >> While I was replying to Stephen Farrell's IESG review, he had a
>     question, and that one brought me another one. I am seeking advice
>     as for how to proceed.
>      >>
>     'accept-wrapped-types. I first proposed these two paragraphs to be
>     added to version -17, however, I have concerns with one of them (see
>     below).
>      >>
>     payload contents, so, for the MSRP switch, the actual payload in
>     instant messages is transparent. So, why should the MSRP switch
>     care? Why should the focus add an 'accept-wrapped-types' at all?
>      >>
>      > I concur. It could use this to express policy about what types it
>     allows, but it could just set it to "*" if it doesn't care.
>
>     +1
>
>      > Do we need to talk about what happens if a _recipient_ does not
>     support a type? I suppose the focus could set accept-wrapped-types
>     based on what all the participants have expressed--but that sounds
>     like a recipe for re-invite storms. The focus could send a 415
>     response to any type where it knows that that one or more recipients
>     cannot accept it.
>
>      >> 2) Stephen Farrel is questioning what should the MSRP switch do
>     if one sender sends an instant message to the chat room, the message
>     containing a type (inside Message/CPIM) that not all the recipients
>     can understand. In other words, the MSRP switch/focus has received
>     SDP indicating that an endpoint supports types A, B, and C. If
>     another participant sends a message with type D, what should the
>     MSRP switch do?
>      >>
>      >> Possibilities include:
>      >> a) Do nothing; forward the message to D, he should deal with the
>     issue. I don't like this, because it is bypassing the MSRP accept-*
>     negotiation.
>      >>
>      >> b) Do not forward the message to this user, but forward to
>     others who accept this type. It is possible that the MSRP switch
>     injects a warning instant message to the sender, indicating this
>     condition.
>      >>
>      >> c) Reject the message to the sender (i.e., do not forward to any
>     user). I don't like this option either, because the poor sender has
>     done nothing wrong. Additionally, this is the dictatorship of the
>     minority (a few people who do not support a type that will be
>     supported by the majority will impose their rules). And it will be
>     so easy to kill a chat room by just logging in supporting only weird
>     type that none else supports.
>      >>
>      > I'm on the fence between B and C. It seems like the undetermined
>     state of "some recipients got it but others didn't" is one of the
>     worst outcomes. I'm not sure I agree about the DoS issue--If a
>     participant wants to screw with the conference, there's lots of
>     other ways he can do so.
>
>      > Another option would be to push a warning to the recipient saying
>     that the someone had sent a type that he had not expressed support for.
>
>      >> I also want to highlight that this is a bit theoretical problem.
>     I expect most implementations to support all commonly known types.
>      >
>      >> Additionally, I expect implementations to add a "*" to indicate
>     support for additional types that have not been explicitly listed,
>     in which case, the MSRP switch will not do any filter, and it is
>     about the endpoint to render the content or not.
>      >
>      > What happens if the recipient sends a 415 response? I guess it's
>     like any other error. That means the sender doesn't learn about it
>     unless the switch synthesis some sort of warning, right?
>      >
>      > I also wonder if switches and/or chat participants should be a
>     little less generous about what types they accept in a chat.
>     Otherwise, this starts to look like a file transfer exploder :-)
>      >
>      >
>      >>
>      >> Comments?
>      >>
>      >> BR,
>      >>
>      >> Miguel
>      >>
>      >> --
>      >> Miguel A. Garcia
>      >> +34-91-339-3608
>      >> Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Sep 2012 13:46:47 -0500

On Sep 11, 2012, at 1:17 PM, "Eric Burger"<[email-masked]> wrote:

> We solved the three-out-of-four endpoints understand D problem years ago. See RFC 3459. UAC's mark the message as critical (gets rejected if unable to send to all recipients) or not critical (gets silently dropped or destination gets a notice).

That's an interesting and likely useful approach. I'm concerned that it's a bit of feature creep for this draft, though. At least, it's a non-trivial feature that the working group had not contemplated so far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort to when we did the delivery status notification work for MESSAGE.

Can we live with some implementor guidance that they need to think about this, and leave a formal solution as future work if anyone wants to do it?

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Sep 2012 13:51:13 -0500

> That's an interesting and likely useful approach. I'm concerned that it's a bit of feature creep for this draft, though. At least, it's a non-trivial feature that the working group had not contempl…

Okay, before anyone jumps on that, on a more careful read of 3459, I realize it would be less work than DSN. But it's still a substantial new feature for this late in the draft's life cycle. That doesn't mean we can't add it if we Really Need It (TM) for the rest of the draft to be useful. Do we?

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Sep 2012 14:10:35 -0500

Correct. That makes it backwards-compatible.

On Sep 11, 2012, at 1:34 PM, Paul Kyzivat wrote:

> So you are suggesting we assume the use of the Content-Disposition header in the CPIM wrapper? And the default is REQUIRED, so the focus should reject the message if it can't be delivered to all recipients and it *doesn't* contain a c-d of OPTIONAL?
> 
> That WFM.
> 
> 	Thanks,
> 	Paul
> 
>> --

---

From: Eric Burger <[email-masked]>
Date: Tue, 11 Sep 2012 14:10:42 -0500

Up to you guys :-)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2012 15:24:25 -0400

> Okay, before anyone jumps on that, on a more careful read of 3459, I realize it would be less work than DSN. But it's still a substantial new feature for this late in the draft's life cycle. That d…

ISTM that now we are realizing we have had the feature all along and 
just never realized it. So there is nothing to do other than maybe point 
out to people that they should do it.

	Thanks,
	Paul

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Sep 2012 14:33:05 -0500

On Sep 11, 2012, at 2:24 PM, Paul Kyzivat <[email-masked]> wrote:

> ISTM that now we are realizing we have had the feature all along and just never realized it. So there is nothing to do other than maybe point out to people that they should do it.

There's still some things to specify. For example, it goes in the CPIM wrapper, not in the MSRP header. You'll only see that once for a chunked message, so it has to become part of the state kept for a chunked message when fast forwarding. You default to "required" if you don't understand 3459 (or the whole thing is "required-to-support", which gives you basically the same thing.)

Did I miss anything?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2012 17:20:37 -0400

> There's still some things to specify. For example, it goes in the CPIM wrapper, not in the MSRP header. You'll only see that once for a chunked message, so it has to become part of the state kept f…

Not sure.

Regarding remembering this as part of the state of the message - maybe, 
and maybe not:

If it remembers 'accept-wrapped-types' for every endpoint, then when 
preparing to forward a message it can identify any endpoints that don't 
support the type, and fail the message before forwarding anything.

But if it wants to handle 415 responses from the forwarded chunks and 
then decide whether to forward the 415 to the sender or not based on 
content-disposition, then it will need to remember that as state.

So maybe this isn't so obvious, which goes to your point of whether this 
is feature creep. But can we dodge it, or not??? And do we want to?

---

From: Ben Campbell <[email-masked]>
Date: Tue, 11 Sep 2012 16:30:43 -0500

On Sep 11, 2012, at 4:20 PM, Paul Kyzivat <[email-masked]> wrote:

> Regarding remembering this as part of the state of the message - maybe, and maybe not:
> 
> If it remembers 'accept-wrapped-types' for every endpoint, then when preparing to forward a message it can identify any endpoints that don't support the type, and fail the message before forwarding anything.
> 
> But if it wants to handle 415 responses from the forwarded chunks and then decide whether to forward the 415 to the sender or not based on content-disposition, then it will need to remember that as state.
> 
> So maybe this isn't so obvious, which goes to your point of whether this is feature creep. But can we dodge it, or not??? And do we want to?

I asked you first :-)

Perhaps the authors will have an opinion.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 12 Sep 2012 15:50:14 +0200

>>> Can we live with some implementor guidance that they need to think about this, and leave a formal solution as future work if anyone wants to do it?

At this point in time, I believe we don't really understand all the use 
cases and problems that we will get when we introduce the 
Content-Disposition handling parameter. Let me give you one example of 
added complexity:

Alice sends a message to the chat room. The MSRP switch distribute to Bob 
and Charlie, because both indicated an accept-wrapped-types of "*". Bob 
accepts the content, but not Charlie. Charlie "MUST take the appropriate 
failure action " [RFC3459], but which one is it? And then, when the MSRP 
switch receives such 'failure action', what should it do towards the 
sender? And should it wait to aggregate 'failure actions' from several 
potential receivers?

So, let's be pragmatical. We don't have time nor requirements to have 
this sophisticated feature at this late point in time. I will try to 
think of something simple (e.g., discard on error). If someone is 
interested, he or she should collect requirements and write an extension.

Is this reasonable? If so, I will come up with text for review?

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 12 Sep 2012 16:01:56 +0200

> Is this reasonable? If so, I will come up with text for review?

This is the text I propose to add. Please comment.

	  When generating a copy of the SEND request to each
	  participant in the chat room, the MSRP switch MUST evaluate
	  the wrapped media types that the recipient is able to
	  accept. This was learned through the 'accept-wrapped-types'
	  attribute of the MSRP message media line in SDP. If the
	  current. If the MSRP switch is aware that the media type of
	  the wrapped content is not acceptable to the recipient, the
	  MSRP switch SHOULD NOT forward this message to that
	  endpoint. Note that this version of the specification does
	  not require the MSRP switch to notify the sender about this
	  failure. Extensions to this specification may improve
	  handling of unknown media types.

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Sep 2012 09:02:11 -0500

On Sep 12, 2012, at 8:50 AM, "Miguel A. Garcia" <[email-masked]> wrote:

[...]

> At this point in time, I believe we don't really understand all the use cases and problems that we will get when we introduce the Content-Disposition handling parameter. Let me give you one example of added complexity:
> 
> Alice sends a message to the chat room. The MSRP switch distribute to Bob and Charlie, because both indicated an accept-wrapped-types of "*". Bob accepts the content, but not Charlie. Charlie "MUST take the appropriate failure action " [RFC3459], but which one is it? And then, when the MSRP switch receives such 'failure action', what should it do towards the sender? And should it wait to aggregate 'failure actions' from several potential receivers?
> 
> So, let's be pragmatical. We don't have time nor requirements to have this sophisticated feature at this late point in time. I will try to think of something simple (e.g., discard on error). If someone is interested, he or she should collect requirements and write an extension.
> 

+1

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Sep 2012 09:05:31 -0500

On Sep 12, 2012, at 9:01 AM, "Miguel A. Garcia" <[email-masked]> wrote:

[...]

> 	  handling of unknown media types.

WFM. I thought about explicitly mentioning the "*" case, where the switch may not learn a format is unacceptable until it tries to send it. But on reflection, I think that's covered implicitly. For this purpose, the "*" case means everything is acceptable.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 12 Sep 2012 16:13:05 +0200

On 12/09/2012 16:05, Ben Campbell wrote:
>>> At this point in time, I believe we don't really understand all
>>> the use cases and problems that we will get when we introduce the
>>> Content-Disposition handling parameter. Let me give you one
>>> example of added complexity:
>>>
>>> Alice sends a message to the chat room. The MSRP switch distribute
>>> to Bob and Charlie, because both indicated an accept-wrapped-types
>>> of "*". Bob accepts the content, but not Charlie. Charlie "MUST
>>> take the appropriate failure action " [RFC3459], but which one is
>>> it? And then, when the MSRP switch receives such 'failure action',
>>> what should it do towards the sender? And should it wait to
>>> aggregate 'failure actions' from several potential receivers?
>>>
>>> So, let's be pragmatical. We don't have time nor requirements to
>>> have this sophisticated feature at this late point in time. I will
>>> try to think of something simple (e.g., discard on error). If
>>> someone is interested, he or she should collect requirements and
>>> write an extension.
>>>
>> When generating a copy of the SEND request to each participant in
>> the chat room, the MSRP switch MUST evaluate the wrapped media types
>> that the recipient is able to accept. This was learned through the
>> 'accept-wrapped-types' attribute of the MSRP message media line in
>> SDP. If the current. If the MSRP switch is aware that the media type
>> of the wrapped content is not acceptable to the recipient, the MSRP
>> switch SHOULD NOT forward this message to that endpoint. Note that
>> this version of the specification does not require the MSRP switch
>> to notify the sender about this failure. Extensions to this
>> specification may improve handling of unknown media types.
>
> WFM. I thought about explicitly mentioning the "*" case, where the
> switch may not learn a format is unacceptable until it tries to send
> it. But on reflection, I think that's covered implicitly. For this
> purpose, the "*" case means everything is acceptable.

Yeah, I thought about adding some text like that, but at the end of the 
day, it will be annotated version of RFC 4575 on accept-wrapped-types, 
meaning, there is no normative text to add. I think we should expect the 
reader to be QUITE familiar with RFC 4975.

Also, I have now added the concept of a policy in the chat room to 
control the Supported Wrapped media type:

	    <t hangText="Supported wrapped media types: ">The list of
	    media types that the MSRP switch accepts in
	    Message/CPIM wrappers sent from participants. This list is
	    included in the 'accept-wrapped-types' attribute of the
	    MSRP message media line in SDP. If the MSRP switch accepts
	    additional media types than those explicitly listed, a "*"
	    is added to the list. A single "*" indicates that the chat
	    room accepts any wrapped media type.

I guess this also hints for what you are saying.

/Miguel

>
>>
>>
>>>
>>> /Miguel
>>>
>>
>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain
>> _______________________________________________ Simple mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/simple
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Sep 2012 12:04:29 -0400

On 9/12/12 9:50 AM, Miguel A. Garcia wrote:
>>>> On Sep 11, 2012, at 1:17 PM, "Eric
>>>> Burger"<[email-masked]> wrote:
>>>>
>>>>> We solved the three-out-of-four endpoints understand D problem
>>>>> years ago. See RFC 3459. UAC's mark the message as critical (gets
>>>>> rejected if unable to send to all recipients) or not critical (gets
>>>>> silently dropped or destination gets a notice).
>>>>
>>>> That's an interesting and likely useful approach. I'm concerned that
>>>> it's a bit of feature creep for this draft, though. At least, it's a
>>>> non-trivial feature that the working group had not contemplated so
>>>> far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent
>>>> effort to when we did the delivery status notification work for
>>>> MESSAGE.
>>>
>>> Okay, before anyone jumps on that, on a more careful read of 3459, I
>>> realize it would be less work than DSN. But it's still a substantial
>>> new feature for this late in the draft's life cycle. That doesn't
>>> mean we can't add it if we Really Need It (TM) for the rest of the
>>> draft to be useful. Do we?
>>
>>>> Can we live with some implementor guidance that they need to think
>>>> about this, and leave a formal solution as future work if anyone
>>>> wants to do it?
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>
> Alice sends a message to the chat room. The MSRP switch distribute to
> Bob and Charlie, because both indicated an accept-wrapped-types of "*".
> Bob accepts the content, but not Charlie. Charlie "MUST take the
> appropriate failure action " [RFC3459], but which one is it? And then,
> when the MSRP switch receives such 'failure action', what should it do
> towards the sender? And should it wait to aggregate 'failure actions'
> from several potential receivers?
>

Yes, I am sympathetic that this is a rat hole that would be good to 
avoid for now.

I just don't want to see something done that *requires* action in 
conflict with what the Content-Disposition would call for. (IOW it 
should be ok for an implementation to be guided by the C-D handling 
parameter if it wishes.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Sep 2012 12:07:17 -0400

On 9/12/12 10:01 AM, Miguel A. Garcia wrote:
>>>>>> rejected if unable to send to all recipients) or not critical
>>>>>> (gets silently dropped or destination gets a notice).
>>>>>
>>>>> That's an interesting and likely useful approach. I'm concerned
>>>>> that it's a bit of feature creep for this draft, though. At least,
>>>>> it's a non-trivial feature that the working group had not
>>>>> contemplated so far. Mapping rfc3459 to MSRP seems like an effort
>>>>> roughly equivalent effort to when we did the delivery status
>>>>> notification work for MESSAGE.
>>>>

Yes, this works for me.

	Thanks,
	Paul

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 13 Sep 2012 10:28:15 +0200

Hi,

> I propose to replace the initially proposed "SHOULD" with a "MAY" in the previous paragraph.

Well, that "never interprets" cannot be guaranteed. I'm toying with an idea for using a specific content type to be used as a control protocol for some specific functionality, for example, so the server would need to interpret it.

Also, in the implementation I've working on, we keep a short history of the messages sent to a room, to give newcomers some context. I don't want to store composing indication chunks and send a newcomer a storm of them, so I'm selective in what I save to this "history".

IIRC private messages sent through the room are actually identified as private after checking the CPIM headers, so checking the From and To headers vs checking the Content-Type in order to validate the wrapped types doesn't make much of a difference, does it?

> So, probably b) is the less worst of all. Comments?

+1 for b.

> I also want to highlight that this is a bit theoretical problem. I expect most implementations to support all commonly known types. Additionally, I expect implementations to add a "*" to indicate support for additional types that have not been explicitly listed, in which case, the MSRP switch will not do any filter, and it is about the endpoint to render the content or not.
> 
> Comments?
> 

I think someone brought this up further down the thread, but given that this is a specification for "chat" shouldn't this specification mandate a lowest common denominator type (for the focus) such as text/plain ?

Regards,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Thu, 13 Sep 2012 10:29:05 +0200

> 	  handling of unknown media types.

+1.

--
Saúl Ibarra Corretgé
AG Projects