Pete, Just a note about the security matter you mention. Some PC based H.323 endpoints allow one, with just a little knowledge, to persuade them to output debugging which includes all elements of decoded RAS/Q.931-H.225.0/H.245 messages. This is clearly "undesirable" when security of information contained in such messages is required! It also might be quite hard for some people to switch off. I don't have a solution to this: I just raise it as an issue. Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis@madge.com

-----Original Message----- From: Pete Cordell [mailto:pete.cordell@BTINTERNET.COM] Sent: 13 May 1999 10:05 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: caller ID and implementer's guide

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@btinternet.com =============================================

-----Original Message----- From: Paul Long <Plong@SMITHMICRO.COM> To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@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@BTINTERNET.COM] Sent: Wednesday, May 12, 1999 6:27 AM To: ITU-SG16@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@btinternet.com =============================================