Re: [sipcore] Extensions to the reg event package

Paul Kyzivat <pkyzivat@cisco.com> Thu, 21 October 2010 17:51 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011B63A6A51 for <sipcore@core3.amsl.com>; Thu, 21 Oct 2010 10:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.498
X-Spam-Level:
X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAO5vfWyhMQ4 for <sipcore@core3.amsl.com>; Thu, 21 Oct 2010 10:51:44 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 01E3F3A6A43 for <sipcore@ietf.org>; Thu, 21 Oct 2010 10:51:43 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar8FANoawExAZnwM/2dsb2JhbACTaY1ycaYwnDCFSgSKTYME
X-IronPort-AV: E=Sophos;i="4.58,218,1286150400"; d="scan'208";a="173474788"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2010 17:53:19 +0000
Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9LHrJdZ022277 for <sipcore@ietf.org>; Thu, 21 Oct 2010 17:53:19 GMT
Message-ID: <4CC07E0F.4030508@cisco.com>
Date: Thu, 21 Oct 2010 13:53:19 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: sipcore@ietf.org
References: <CD5674C3CD99574EBA7432465FC13C1B220228896A@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B220228896A@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Extensions to the reg event package
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Oct 2010 17:51:45 -0000

My knowledge of XML schemas is limited to cutting and pasting from 
existing ones, and attempting to follow apparent conventions I see used.
(Equivalent to implementing SIP based on wireshark output.)

It would be great if somebody who knows better were to write a best 
practices document for applying XML to SIP stuff. And perhaps there 
should be some sort of official XML review of drafts.

	Thanks,
	Paul

On 10/21/2010 1:44 PM, Worley, Dale R (Dale) wrote:
> I've noticed that extensions to the reg event package are done by introducing new namespaces.  Since extensions usually add only one or two data items to the package, the result can be an XML document with many namespaces,  most of which have a very few element types being used.  It seems to me to be more natural for extensions to add elements to the original XML schema.  And since the interpreter of the XML document will ignore any elements that it does not recognize, this practice would be upward-compatible.  I suspect that there is some formal reason why extending an existing namespace is not done.
>
> Dale
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>