Subject: RE: [BLISS] Welcome! Main question - what services?

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 1 Feb 2007 10:09:00 +0100

For all the services when used in the PSTN/ISDN the general intent has
to make these services more generally available to all services AS
APPROPRIATE.

Thus to take for example DND, on the PSTN, there it was primarily
applicable to voice, because voice was the main service used on the
PSTN. In fact it would be more correct to say when activated it applied
generally to all services, thus if you had a fax machine on the same
line, that was also affected  by invocation of the service.

With the introduction of the ISDN, and the ability to recognise the
requested service or communication type in the network and the terminal,
the service expanded to allow it to be invoked for specific services or
communication types, whereas for example DND would not apply on others.

I don't see why we cannot extend this argument to the work in BLISS. 

If the service makes sense for any SIP capability, then define it for
that. 

DND can be applied (if desired) for any request that is not in an
existing dialog. 

Taking call park as an example, it obviously cannot be applied as
currently understood to capabilities supported by MESSAGE requests, due
to the transitory nature of such capabilities, but there is no reason
why it cannot be applied, either generically or for specific SDPs, to
any INVITE initiated dialog.

Regards

Keith

> -----Original Message-----
> From: Shida Schubert [mailto:[email-masked]] 
> Sent: 31 January 2007 21:48
> To: Peili Xu
> Cc: [email-masked]
> Subject: Re: [BLISS] Welcome! Main question - what services?
> 
> 
> Hi Peili;
> 
> Session mode messaging service as I mentioned in the response 
> to Spencer is not in scope of BLISS. I will modify the text 
> that raised this question.
> 
> Thanks.
> Shida
> 
> Peili Xu wrote:
> > After looking at the following sentences in the draft charger "The 
> > difference between SIPPING and BLISS, is that BLISS is focused on a 
> > particular type of SIP application - call features, and in 
> particular, 
> > advanced call features requiring non-trivial call control. SIP 
> > applications such as configuration, presence and IM, and session 
> > policy are clearly out of scope for BLISS and remain the 
> sole province of SIPPING. "
> >
> > It seems the WG will actually focus on features initiated by INVITE 
> > and these features are more or less related to traditional 
> PSTN/ISDN 
> > supplementary services.
> > If I am correct, what about session mode messaging service which is 
> > also a call initiated by INVITE?
> >
> > thanks
> > Peili
> >
> > -----Original Message-----
> > From: Shida Schubert [mailto:[email-masked]]
> > Sent: Saturday, January 27, 2007 2:29 AM
> > To: Jonathan Rosenberg
> > Cc: Miguel Garcia; [email-masked]
> > Subject: Re: [BLISS] Welcome! Main question - what services?
> >
> >
> > I tried to incorporate some of the comments provided in the 
> last week 
> > including the one below to the charter.
> > Updated charter is available at
> >
> > http://www.bliss-ietf.org/charter.html
> >
> > diff is available at http://www.bliss-ietf.org/diff1.html
> >
> > Shida
> >
> >
> > Jonathan Rosenberg wrote:
> >   
> >> OK, I think this is a reasonable change to the charter.
> >>
> >> -Jonathan R.
> >>
> >> Miguel Garcia wrote:
> >>
> >>     
> >>> Jonathan Rosenberg wrote:
> >>>
> >>>       
> >>>> Miguel Garcia wrote:
> >>>>
> >>>>         
> >>>>> I think it is reasonable to work on the approach that 
> you propose, 
> >>>>> Jonathan. I have a couple of questions and comments about the 
> >>>>> proposed charter.
> >>>>>
> >>>>> 1) When the charter speaks about heterogeneous 
> networks, does it 
> >>>>> refer only to SIP networks or does it consider interoperability 
> >>>>> across, say, the PSTN. I am sure the TISPAN guys will ask this 
> >>>>> question sooner or later, so better to write the 
> answer, whatever 
> >>>>> it is, in the charter.
> >>>>>           
> >>>> Its referring to SIP neworks. The heterogeneity refers to 
> >>>> endpoints, which includes gateways to the PSTN. Thus, 
> the idea was 
> >>>> most definitely to take into considerating how a gateway might 
> >>>> implement these services due to the fact that it is a 
> gateway, and 
> >>>> is trying to interwork to another network.
> >>>>
> >>>> This is captured in the charter already here:
> >>>>
> >>>> "The problem is exacerbated by the desire for these features to 
> >>>> work across many types of SIP endpoints, including SIP 
> hardphones, 
> >>>> softphones, and gateways to the PSTN and other VoIP 
> networks, and 
> >>>> for the desire to work across domain boundaries."
> >>>>
> >>>> Can you suggest some additional text to clarify?
> >>>>         
> >>> I am satisfied with your explanation. When I read the charter I 
> >>> interpreted "domain boundaries" as in "SIP domain 
> boundaries", but I 
> >>> understand now that you mean crossing to the PSTN, for 
> example. If 
> >>> you want, you could add make the sentence to read "... 
> and for the 
> >>> desire to work across domain boundaries and to seamless interwork 
> >>> with the PSTN, when applicable".
> >>>
> >>> /Miguel
> >>>
> >>>
> >>>
> >>>       
> >
> >
> > _______________________________________________
> > BLISS mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/bliss
> >
> >
> >
> >   
> 
> 
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bliss
> 

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

---

From: Shida Schubert <[email-masked]>
Date: Thu, 01 Feb 2007 03:03:21 -0800

I do think the argument can work, I believe optimally BLISS should always
keep various capabilities in mind when conducting the analysis and
documenting
the variations. We should also make sure we get the best out of what SIP
has
to offer, and not limit the possibilities just because the pre-existing
service is
offered in a certain way. (I do want to stress though that I don't want to
hinder the work for "nice to have" or "may be nice to have" feature that
never gets implemented.)

If the variations include different media such as MSRP or the call
feature is
best served by using presence, I do think we should look into them and ask
appropriate workgroup for an extensions if one is needed. I have no
problems
with that and rather supportive of that..

But defining services solely used by session based messaging and
presence has
a home called SIMPLE at this present moment, and I see no reasons why BLISS
should take on them as long as SIMPLE exists.

Thought?

Regards
Shida

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Feb 2007 09:09:42 -0500

I have been inovlved in an exercise of trying to map traditional PSTN 
services to SIP, and make them apply more generally to the broader set 
of things that can happen in SIP.

Some services seem to apply to an AOR, others to a UA, and some 
potentially to a particular media stream. And in some cases there are 
multiple meaningful ways to apply the service. For instance:

- DND can meaningfully apply at either the AOR level or the UA level.
   You could consider these to be different services.

- HOLD can apply to a whole dialog, or to a particular media stream
   within a dialog.

Its important to consider these things.

	Paul

---

From: [email-masked]
Date: Thu, 1 Feb 2007 09:58:24 -0500

From: Shida Schubert <[email-masked]>

   But defining services solely used by session based messaging and
   presence has a home called SIMPLE at this present moment, and I see
   no reasons why BLISS should take on them as long as SIMPLE exists.

I don't know about presence.  But within the SIP philosophy,
session-based messaging is "just another media type" when compared to
audio calling.  So it seems to me that if we discern an apparent
difference in "calling features" between session-based messaging and
audio calling, we are probably misunderstanding the situation.

Dale

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 01 Feb 2007 17:01:51 +0200

DND can also apply to a particular media stream. In particular, if I am 
in a meeting, I may want to activate the DND for audio and video, but 
not for messaging.

I guess in general, you need to consider all the different media streams 
that can apply to service. It would be a big mistake just to restrict to 
audio or to "things that are initiated with an INVITE" because this is 
what the PSTN did.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 1 Feb 2007 16:08:34 +0100

I assume that you mean you wish to be DND to a request with a SIP offer
of a particular media stream, rather than just DND to a particular media
stream.

Regards

Keith 

> From: Miguel Garcia [mailto:[email-masked]] 
> Sent: 01 February 2007 15:02
> To: Paul Kyzivat
> Cc: Drage, Keith (Keith); [email-masked]
> DND can also apply to a particular media stream. In 
> particular, if I am in a meeting, I may want to activate the 
> DND for audio and video, but not for messaging.
> 
> I guess in general, you need to consider all the different 
> media streams that can apply to service. It would be a big 
> mistake just to restrict to audio or to "things that are 
> initiated with an INVITE" because this is what the PSTN did.
> 
> /Miguel
> 
> Paul Kyzivat wrote:

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 01 Feb 2007 17:12:59 +0200

Right... the capability of indicating a DND for SIP offers that contain 
certain media streams. Similarly with SIP methods.

/Miguel

---

From: [email-masked]
Date: Thu, 1 Feb 2007 10:27:42 -0500

From: Miguel Garcia <[email-masked]>

I assume you mean "media type" here -- a media stream is what is
established by an m line in the SDP of an existing dialog.  But you
couldn't apply DND to a media *stream* until it exists, and at that
point, it's too late.

Dale

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 1 Feb 2007 16:30:44 +0100

Agreed.

It is these type of considerations that allow to actually know whether
the service makes sense in its new environment. They do need to form
part of any requirements analysis in the proposed BLISS.

Keith 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 01 February 2007 14:10
> To: Drage, Keith (Keith)
> Cc: [email-masked]; Peili Xu; [email-masked]
> I have been inovlved in an exercise of trying to map 
> traditional PSTN services to SIP, and make them apply more 
> generally to the broader set of things that can happen in SIP.
> 
> Some services seem to apply to an AOR, others to a UA, and 
> some potentially to a particular media stream. And in some 
> cases there are multiple meaningful ways to apply the 
> service. For instance:
> 
> > PSTN. In fact it would be more correct to say when activated it 
> > applied generally to all services, thus if you had a fax machine on 
> > the same line, that was also affected  by invocation of the service.
> > 
> > requested service or communication type in the network and the 
> > terminal, the service expanded to allow it to be invoked 
> for specific 
> > services or communication types, whereas for example DND 
> would not apply on others.
> > 
> > currently understood to capabilities supported by MESSAGE requests, 
> > due to the transitory nature of such capabilities, but there is no 
> > reason why it cannot be applied, either generically or for specific 
> > SDPs, to any INVITE initiated dialog.
> > 
> > Regards
> > 
> > Keith
> > 
> > 
> > 
> >> Session mode messaging service as I mentioned in the response to 
> >> Spencer is not in scope of BLISS. I will modify the text 
> that raised 
> >> this question.
> >>
> >> Thanks.
> >> Shida
> >>
> >> Peili Xu wrote:

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 01 Feb 2007 17:38:40 +0200

Correct, s/media stream/media type

/Miguel

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 01 Feb 2007 09:58:38 -0600

I agree with Keith, Peili, and Paul here.

I am sympathetic to the need to get something out quickly, but also see the 
need for requirements analysis, so we don't codify patterns that don't work 
in situations that we weren't thinking about.

Spencer

From: "Drage, Keith (Keith)" <[email-masked]>

Sent: Thursday, February 01, 2007 9:30 AM
Subject: RE: [BLISS] Welcome! Main question - what services?

Agreed.

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Feb 2007 12:14:24 -0500

I don't think I buy this flavor of DND. I think it will cause interop 
problems.

IMO the key aspect of DND is about alerting. Which media that are 
eligible to be used may also be relevant, but I think it is an 
orthogonal issue.

For instance, if you are willing to use MSRP, but not audio or video, 
then your UA can reject offered audio and video media streams while 
accepting msrp streams. If rejecting audio and video means that no 
offered streams are being accepted, then the UA may indeed want to 
reject the call without alerting. But I don't think that is DND.

AFAIK DND only applies during session establishment. Willingness to use 
media streams applies to mid-call changes as well.

I think there is a very interesting subject of how media in a call are 
negotiated and changed. This is relatively clear from an O/A 
perspective, but when you start to consider user preferences at each end 
and how they can change mid call it gets much less clear. (E.g. when you 
have audio/video capable UAs you often will want to start with video 
disabled, and then maybe enable it later. But both ends need to enable 
before it can be used. Requires a little more that existing O/A to 
support a plausible UI.) While interesting, I think this probably falls 
into the category of "advanced" features.

	Paul

Miguel Garcia wrote:
>>    DND can also apply to a particular media stream. In particular, if 
>> I am    in a meeting, I may want to activate the DND for audio and 
>> video, but    not for messaging.
>>

---

From: Shida Schubert <[email-masked]>
Date: Thu, 01 Feb 2007 11:43:44 -0800

Hi Dale;

I think we are on the same page.

As I mentioned in another e-mail, I see session based
messaging as just another media, and I don't think special
attention is needed for the session based messaging as it's
just another media, the service invocation would doubtfully
be different..

 What I was trying to state below is if there is a service
needed to be defined which is to be utilized only by
session based messaging(a specific media), I don't think
BLISS is the place to do it(chat based on session based
messaging for example).

Regards
Shida

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Feb 2007 14:59:45 +0200

Inline discussion.

> I don't think I buy this flavor of DND. I think it will cause interop 

This is exactly what BLISS has to solve, avoid interop problems.

> eligible to be used may also be relevant, but I think it is an 

I agree that DND is about alerting. The conditions to indicate such 
alerting cases are driven by the user, and the user should be able to 
set such conditions based on whatever parameters he wants. Perhaps based 
on time (connected to calendar), based on present media types in the 
Offer as we discussed earlier, etc.

> reject the call without alerting. But I don't think that is DND.

I agree that rejecting media is not DND, and I agree that DND is about 
alerting. So I don't think we shouldn't be discussing the rejecting 
aspects, which are not DND. We should be discussing when the alert is 
delivered to the end user, and I am saying that this not a binary 
operation, but they are many inputs to that decision.

> media streams applies to mid-call changes as well.

Agreed too.

> into the category of "advanced" features.

Agreed too.

/Miguel

---

From: [email-masked]
Date: Fri, 2 Feb 2007 11:05:04 -0500

From: Paul Kyzivat <[email-masked]>

I don't see this as troublesome.  Whenever either end changes its
"allow video" status, it initiates a re-INVITE cycle.  Video will only
beenabled when both ends have "allow video" set.

For example:

	A				B

	(no video)			(no video)

	INVITE (audio) -->
					<-- 200 (audio)

			only audio passes

	(user A enables video)

	reINVITE (audio, video) -->
					<-- 200 (audio)

			only audio passes

					(user B enables video)

					<-- reINVITE (audio, video)
	200 (audio, video) -->

			audio and video pass

	(user A disables video)

	reINVITE (audio) -->
					<-- 200 (audio)

			only audio passes

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Feb 2007 13:01:15 -0500

Dale,

what you outline will work. But when A enabled video he presumably was 
interested in having it. But B (the human) doesn't know that. So it 
requires some other jog for B to enable video.

There has been some discussion off and on that when the reinvite comes 
with a video offer, B should alert its user and ask for confirmation. 
But I think that will cause problems. An alternative is for the device 
to note that it has been offered something that it could support but 
that is currently disabled, and to display an indicator to that effect. 
This gives the user the hint that he might want to enable his end.

I'm not suggesting that we want to standardize these kinds of UI 
behaviors. And I think we have all the signaling mechanisms needed to 
make this work. But I think we have the potential for poor interop 
unless some use cases are worked through, and some best practices 
identified. The most obvious problem is if some devices start alerting 
on reinvite with new media while others depend on reinvites completing 
immediately without alerting.

Another interesting case is whether a device should ever accept a call 
while rejecting all the media offered in the call. If it does, it might 
prevent the call from being answered by a different device that supports 
at least one of the offered media. But in some cases there might be 
value in answering. (E.g. if you have your audio+im phone set to im-only 
and a voice-only call comes in, maybe you want it to let you answer 
without the audio, offer IM back, and if that fails let you know so you 
can go someplace else and enable the audio.)

I expect there are many of these mixed mode use cases, intimately tied 
to the UI on the device. We need to "let a 1000 flowers bloom" here, but 
at the same time maximize the interoperability of them all. (I certainly 
don't want to see every one identified as a separate "service" that can 
only talk to another device that supports the same service.)

	Paul

---

From: [email-masked]
Date: Fri, 2 Feb 2007 16:06:04 -0500

But I think we have the potential for poor interop unless some use
   cases are worked through, and some best practices identified.

Ah, yes, a subtle and interesting point -- we have standardized all
the mechanisms that we need, but unless we *restrict* them with good
BCPs, interoperability suffers.  I believe that I didn't notice this
because I tend to have strong opinions about how mechanisms should be
used, and didn't realize the interop problems if someone else does
things differently.

Ugh.  It seems like rejecting the call will almost always be best (but
that assumes that the caller proposes all media that he would be
willing to accept under any circumstances).

BTW, what error should a UA use in this case?  It seems that 488 is
correct, but the writeup in 3261 almost makes that sound improper.
(Or is this coverd in the new offer/answer I-D?)

   (I certainly don't want to see every one identified as a separate
   "service" that can only talk to another device that supports the
   same service.)

Yes, the automatic fallback to the
highest-shared-level-of-functionality is one of the strengths of the
Internet design philosophy.  And this is commercially important, too
-- I've seen presentations given to telecomm operators by SIP
equipment vendors, and a major selling point is "no profiles are
needed", that when you interconnect two vendors' SIP equipment, they
figure out what they have in common with no specific configuration.
It seems with traditional telecomm equipment, someone sits down and
figures out the lowest common denominator, and then configures
everything to know that they can only use those features.

Which is why the "service identifier" work seems strange to me -- it's
clear that the service identifiers are intended to be Requires
features, but in most cases that assumes that both endpoints have to
know that they both support the same feature before they can
interconnect at all.

Dale

---

From: Göran Eriksson AP (KI/EAB)<[email-masked]>
Date: Fri, 2 Feb 2007 23:55:25 +0100

Hi Paul,

		I'm not suggesting that we want to standardize these kinds of UI behaviors. 
		And I think we have all the signaling mechanisms needed to make this work. 
		But I think we have the potential for poor interop unless some use cases are 
		worked through, and some best practices identified.

You mean defining best practice in the UI design (human-device/system interaction) for a particular type of "service", right?

Assuming You have that in mind, You're saying don't standardise the UI behaviour but describe best practice. How does that solve
the problem (in any way different than standardisation)? Is it that we will only "standardise", with BCP, a part of the
service behaviour (as seen from the end user)?

Regards
Göran

PS. 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: den 2 februari 2007 19:01
To: [email-masked]
Cc: [email-masked]
Subject: Re: [BLISS] Welcome! Main question - what services?

Dale,

what you outline will work. But when A enabled video he presumably was interested in having it. But B (the human) doesn't know that. So it requires some other jog for B to enable video.

There has been some discussion off and on that when the reinvite comes with a video offer, B should alert its user and ask for confirmation. 
But I think that will cause problems. An alternative is for the device to note that it has been offered something that it could support but that is currently disabled, and to display an indicator to that effect. 
This gives the user the hint that he might want to enable his end.

I'm not suggesting that we want to standardize these kinds of UI behaviors. And I think we have all the signaling mechanisms needed to make this work. But I think we have the potential for poor interop unless some use cases are worked through, and some best practices identified. The most obvious problem is if some devices start alerting on reinvite with new media while others depend on reinvites completing immediately without alerting.

Another interesting case is whether a device should ever accept a call while rejecting all the media offered in the call. If it does, it might prevent the call from being answered by a different device that supports at least one of the offered media. But in some cases there might be value in answering. (E.g. if you have your audio+im phone set to im-only and a voice-only call comes in, maybe you want it to let you answer without the audio, offer IM back, and if that fails let you know so you can go someplace else and enable the audio.)

I expect there are many of these mixed mode use cases, intimately tied to the UI on the device. We need to "let a 1000 flowers bloom" here, but at the same time maximize the interoperability of them all. (I certainly don't want to see every one identified as a separate "service" that can only talk to another device that supports the same service.)

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Feb 2007 18:19:40 -0500

> You mean defining best practice in the UI design (human-device/system interaction) for a particular type of "service", right?

No. I mean defining best practice in sip (and sdp o/a) usage so that the 
various scenarios that people come up with can work and interoperate 
reasonably when the two ends don't have the same UI.

---

From: Göran Eriksson AP (KI/EAB)<[email-masked]>
Date: Sat, 3 Feb 2007 00:26:15 +0100

interoperate reasonably 

Sorry for being picky or perhaps just a bit slow this late in the evening in the dark Nordic night, but interoperate from which perspective?

OK, not the way interaction design details like buttons color, etc, but at least interaction design in terms
of what the user expects from the "system", read device, and how he/she interacts with it to achieve some result, right?

Let's not call it UI design but it is then getting us into defining the user-system interaction, or rather describing
a best practice for it?

BR
Göran

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: den 3 februari 2007 00:20
To: Göran Eriksson AP (KI/EAB)
Cc: [email-masked]; [email-masked]
Subject: Re: [BLISS] Welcome! Main question - what services?

> You mean defining best practice in the UI design (human-device/system interaction) for a particular type of "service", right?

No. I mean defining best practice in sip (and sdp o/a) usage so that the various scenarios that people come up with can work and interoperate reasonably when the two ends don't have the same UI.

> Assuming You have that in mind, You're saying don't standardise the UI 
> behaviour but describe best practice. How does that solve the problem 
> (in any way different than standardisation)? Is it that we will only "standardise", with BCP, a part of the service behaviour (as seen from the end user)?
> 
> Regards
> Göran
> 
> PS. 
>  
> 
> while rejecting all the media offered in the call. If it does, it 
> might prevent the call from being answered by a different device that 
> supports at least one of the offered media. But in some cases there 
> might be value in answering. (E.g. if you have your audio+im phone set 
> to im-only and a voice-only call comes in, maybe you want it to let 
> you answer without the audio, offer IM back, and if that fails let you 
> know so you can go someplace else and enable the audio.)
> 
> to the UI on the device. We need to "let a 1000 flowers bloom" here, 
> but at the same time maximize the interoperability of them all. (I 
> certainly don't want to see every one identified as a separate 
> "service" that can only talk to another device that supports the same 
> service.)
> 
> 	Paul
> 
>> "allow video" status, it initiates a re-INVITE cycle.  Video will 
>> only beenabled when both ends have "allow video" set.
>>
>> For example:
>>
>>
>> 	A				B
>>
>> 	(no video)			(no video)
>>
>> 	INVITE (audio) -->
>> 					<-- 200 (audio)
>>
>> 			only audio passes
>>
>> 	(user A enables video)
>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 16 Feb 2007 16:44:34 -0500

To summarize this discussion, I think its fair to say that *anything* 
that BLISS does will consider multimedia (audio, video, messaging, and 
of course - text). I also think we should add that explicitly to the 
charter to be clear. As Paul and others have said, in some cases the 
flows may really not care at all what the media types are; for others it 
may matter, or we at least need to think about whether they matter.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: [email-masked]
Date: Mon, 19 Feb 2007 12:04:15 -0500

From: Jonathan Rosenberg <[email-masked]>

   As Paul and others have said, in some cases the flows may really
   not care at all what the media types are; for others it may matter,
   or we at least need to think about whether they matter.

If the media matters, it's likely we've made a mistake.

Dale