caller ID and implementer's guide

Pete Cordell pete.cordell at BTINTERNET.COM
Thu May 13 05:04:52 EDT 1999


Paul,

I now understand where you are coming from when you say that the first
scheme is proprietary.

However, I think it's slightly different because, although someone might be
upset if you sent H.261 data to an H.263 decoder, they are unlikely to sue
you for disclosing information that has been requested to be kept private,
as might be the case if the calling party's telephone number is displayed
when it has been requested not to be.  Hence the need for trust, because if
the entity you send the information to does not honour your request, you
could end up with some very expensive legal fees!

(As a side note, some sort of calling party id is probably required for
legal reasons, such as tracing emergency calls.  Hence remaining private by
not including the calling party id is not an option.  I'm not sure if this
is what we are talking about , but what is really needed is something that
only lets those that are allowed to know to access the information.  The
case of the switched network is slightly different to that of IP because the
former is essentially a secure network behind a firewall.  The Internet and
most other IP networks does not generally mirror this model and so a
different solution is required.  What is probably required is a
supplementary service that does call tracing using suitable
cryptographically secure tokens that are known only to those that are
allowed to do call tracing.)

Pete

=============================================
Pete Cordell
pete.cordell at btinternet.com
=============================================

-----Original Message-----
From: Paul Long <Plong at SMITHMICRO.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: 12 May 1999 14:20
Subject: Re: caller ID and implementer's guide


>Pete,
>
>Sorry. I did indeed believe that you were saying that a vendor could take
>ownership of an IE, which would be a proprietary and rather dangerous
>solution. "We" or "SG16" in place of "you" might have been a better choice
of
>words. Your first solution is still proprietary, though. Your counter
argument
>is weak because one could use it for all otherwise proprietary features,
e.g.,
>"only send H.261 on a channel established for H.263 to an entity that you
>trust to expect this."
>
>Paul Long
>Smith Micro Software, Inc.
>
>        -----Original Message-----
>        From:   Pete Cordell [SMTP:pete.cordell at BTINTERNET.COM]
>        Sent:   Wednesday, May 12, 1999 6:27 AM
>        To:     ITU-SG16 at MAILBAG.INTEL.COM
>        Subject:        Re: caller ID and implementer's guide
>
>        Paul,
>
>        I disagree that these are proprietary solutions.
>
>        The first is a matter of policy and so falls into a slightly grey
>area, but
>        ideally the standard would say something like 'only send
presentation
>        restricted information to an entity that you trust to honour the
>request.'
>
>        The second is definitely NOT an action you could take at a
proprietary
>level
>        as the standards body still holds the right to define new IEs.  Any
>such
>        action would have to be approved by the standards body.  When I
said
>'...YOU
>        could take further ownership...', the 'you' was intended to refer
to
>SG16.
>
>        As such a change is small and localised, it would be safe to
implement
>it
>        even if it was mentioned only in a determined document (which is
the
>way the
>        procedure is supposed to work after all anyway!) which could be
>achieved at
>        the Chile meeting.  A fix in the ASN.1 would have to wait for the
>decided
>        version as that needs to wait until all such additions are present.
>
>        Pete
>
>        =============================================
>        Pete Cordell
>        pete.cordell at btinternet.com
>        =============================================
>
>



More information about the sg16-avd mailing list