Re: [dispatch] RFC 3680 extensibility

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 14 June 2010 09:17 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A54A3A684E for <dispatch@core3.amsl.com>; Mon, 14 Jun 2010 02:17:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.634
X-Spam-Level:
X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599]
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 Qncbuak1d8pP for <dispatch@core3.amsl.com>; Mon, 14 Jun 2010 02:17:53 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4EED63A688E for <dispatch@ietf.org>; Mon, 14 Jun 2010 02:17:52 -0700 (PDT)
X-AuditID: c1b4fb39-b7b80ae000001aa1-10-4c15f3c346e4
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DC.87.06817.3C3F51C4; Mon, 14 Jun 2010 11:17:55 +0200 (CEST)
Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 14 Jun 2010 11:17:42 +0200
Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 14 Jun 2010 11:17:29 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "WORLEY, Dale R (Dale)" <dworley@avaya.com>
Date: Mon, 14 Jun 2010 11:17:28 +0200
Thread-Topic: [dispatch] RFC 3680 extensibility
Thread-Index: AcsLjLzuaWegSaUoQum0BgCgTNvXKAAFZ0IQ
Message-ID: <FF84A09F50A6DC48ACB6714F4666CC7465C63985AF@ESESSCMS0354.eemea.ericsson.se>
References: <FF84A09F50A6DC48ACB6714F4666CC7465C6398042@ESESSCMS0354.eemea.ericsson.se> <CD5674C3CD99574EBA7432465FC13C1B21FD736182@DC-US1MBEX4.global.avaya.com> <4C15CF4C.8060506@ericsson.com>
In-Reply-To: <4C15CF4C.8060506@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: DISPATCH list <dispatch@ietf.org>
Subject: Re: [dispatch] RFC 3680 extensibility
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jun 2010 09:17:54 -0000

Hi,

So, it would be the same policy as we have for info packages.

Thanks!

Regards,

Christer

 

> -----Original Message-----
> From: Gonzalo Camarillo 
> Sent: 14. kesäkuuta 2010 9:42
> To: WORLEY, Dale R (Dale)
> Cc: Christer Holmberg; DISPATCH list
> Subject: Re: [dispatch] RFC 3680 extensibility
> 
> Hi,
> 
> yes, I agree with Dale that, technically, the system is ready 
> to handle interoperability even in presence of unknown 
> stuff... but the question here is whether or not we have a 
> policy that regulates the creation of such extensions.
> 
> XML namespaces are not covered by RFC 5727. However, Section 
> 4.2 of RFC
> 3863 specifies rules for registering extensions to the basic 
> presence information data format:
> 
> http://tools.ietf.org/html/rfc3863#section-4.2
> 
> Considering the spirit of RFC 5727 and the example above, a 
> potential policy could be to register reg-event extensions 
> with the IANA using the Specification Required policy defined 
> in RFC 5226. In this case, this would mean that the extension 
> would be defined in a 3GPP spec and revised by an expert who 
> would be designated by the RAI ADs. The expert reviewer would 
> make sure that new extensions do not overlap with current IETF work.
> 
> In any case, we would welcome further comments on this issue.
> 
> Thanks,
> 
> Gonzalo
> 
> 
> On 11/06/2010 7:06 PM, WORLEY, Dale R (Dale) wrote:
> > ________________________________________
> > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] 
> On Behalf 
> > Of Christer Holmberg [christer.holmberg@ericsson.com]
> > 
> > Section 5.1 of RFC 3680 (reg event package) says:
> > 
> > "Other elements from different namespaces MAY be present for the 
> > purposes of extensibility; elements or attributes from unknown 
> > namespaces MUST be ignored."
> > 
> > However, there is no policy regarding whether the 
> definition of these "other namespaces" needs to be done in 
> IETF - only that they must be ignored if not supported.
> > 
> > 3GPP has been discussing a couple of IMS specific cases, in 
> which such extension elements/attributes could be used as 
> solution (no decissions have been made yet), so the question 
> is whether it would require IETF work.
> > ________________________________________
> > 
> > The rule that unknown elements/attributes must be ignored 
> covers you there, doesn't it?  If a non-3GPP system 
> subscribes to an "extended" event package, it will ignore the 
> extensions.
> > 
> > Dale
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
> > 
> 
>