Re: [netmod] for a future rfc6991bis

Balázs Lengyel <balazs.lengyel@ericsson.com> Tue, 13 November 2018 13:33 UTC

Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08FF130934 for <netmod@ietfa.amsl.com>; Tue, 13 Nov 2018 05:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.792
X-Spam-Level:
X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Sh1BpL7A; dkim=pass (1024-bit key) header.d=ericsson.com header.b=UdlVbM01
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHlzv_bMsvEF for <netmod@ietfa.amsl.com>; Tue, 13 Nov 2018 05:33:06 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570C21276D0 for <netmod@ietf.org>; Tue, 13 Nov 2018 05:33:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1542115983; x=1544707983; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=9fIAgKRifpAVdmyzH582wOGKUhnyrAmqF+PwcJftOxo=; b=Sh1BpL7AidlLgVZDzBUAzPloBgN6xA8BeCmINHLpx6kvQjoci+5Jgi1pQyey9r00 LYSJW6pthGOVIyMCYRWobikBLk8cOt0UanDL8NlzcSWRoL/nN6fkevI61Fy6BA4m EgGds37mopIv7UsmT5dekGul00j6/LHLaXsxR5+EjV8=;
X-AuditID: c1b4fb30-f2dff700000043c4-ee-5bead28f796f
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 73.B6.17348.F82DAEB5; Tue, 13 Nov 2018 14:33:03 +0100 (CET)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 13 Nov 2018 14:33:03 +0100
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 13 Nov 2018 14:33:03 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hFV8uMectyJYe3tsfReVg419l4Vt4EA92J4auOOhU58=; b=UdlVbM01x07n25kUaVCUgV9z5Kx/jAZWpw6AsKvtznBYC0mR0LM06BwQKN35nA6vgcgmh3KL2TE5WIWzEG+xnAE8Jp+TW4QnK53AsVaIE2WZg//uouMkykxzrkrd38KPHZnT+AeATItJLloJvI++B+4vc0YXpzFlMpukVytRDTM=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2751.eurprd07.prod.outlook.com (10.173.81.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.10; Tue, 13 Nov 2018 13:33:02 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1339.019; Tue, 13 Nov 2018 13:33:02 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
To: "Yemin (Amy)" <amy.yemin@huawei.com>, Qin Wu <bill.wu@huawei.com>, "Xufeng Liu" <xufeng.liu.ietf@gmail.com>, NETMOD WG <netmod@ietf.org>
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUe1VmbTarS7Bo30CiE6gJ+Dl/9w==
Date: Tue, 13 Nov 2018 13:33:01 +0000
Message-ID: <0bb4d572-3378-c46a-0802-c2c2fce7cc4e@ericsson.com>
References: <B8F9A780D330094D99AF023C5877DABA9B0FC256@nkgeml513-mbs.china.huawei.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com> <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com> <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
x-clientproxiedby: AM6PR07CA0016.eurprd07.prod.outlook.com (2603:10a6:209:2a::29) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2751; 6:bWxcJE5iAHeC3h4+7hOhqhuWhSoSOwzDh2Are04XbSj1X2x9hwami4hYYnDZw1N4x/WbINgcuNTY5F5DwG7vmXx6CHfc7oEFuIuciAPlDx15xMTPEFqfIuwWP7zz3UgbIsRCHqT/ePOeRNxv1WDJokEACr504M+evA9n2YQpRTLp0IZb31qUeuVXNqFOAONE0/bfdBTlMcr+Y9fBZfFPIgXk6A72vuBM57fJC1G1g1sW+8pYlDNuB+DHnAbf8Jbtt2ehGVUPYY3SGhBq85g/SsnueH22cuJm7r8oKel1vzN3LQnnfyaGVznfrDZ+Wj4m36KzZAR/pLjVLgYaZnJ4pYiS6Vhwk8FMayguUYPjRidJprRjeMOA8+QGxcWF6LMFDB6tWcpkK+Cf5LfajFxAJ1x5lkp/mHVsYmo3rTRIZFeeyDF5RjKEdm5LeLyRhL8z/jb2oQvkcflsUBQ2zLix8g==; 5:E4RzM95UsDJgX9+dA50DZ7lDyfPYlO8o4I2KlRq77aM8U8iy8+iRwt6juR7qiQvQd9FKpZLRjV+9fYfNULQ775a+hPwBdRm77wEVnWz1wbA+K4jT1p+cIln+k9AHZ9FTHAlF2zDI5Gnak50UxCRe4Ktu8Bc6/Z9pG267zbideUo=; 7:tggA00nR9/A2phdUkz2PK+tKTuDNxKINhPTU4PD92u67iR5uv0AaOTHyddb3d6GvIXH45ep+5dAfO1g6ve3hsapm7h0izs0ik5RiqpqdFYPiUIAXUX81zOjfFwwN+ayO98c9oPN39QQplquviVMaNQ==
x-ms-office365-filtering-correlation-id: 90e70861-8f6b-416e-fcbd-08d6496c8875
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2751;
x-ms-traffictypediagnostic: VI1PR0701MB2751:
x-microsoft-antispam-prvs: <VI1PR0701MB2751435191289BDF20E71EF9F0C20@VI1PR0701MB2751.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231382)(944501410)(4983020)(52105112)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2751; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2751;
x-forefront-prvs: 085551F5A8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(366004)(396003)(376002)(136003)(346002)(189003)(252514010)(199004)(13464003)(966005)(305945005)(105586002)(93886005)(97736004)(446003)(106356001)(86362001)(26005)(6486002)(11346002)(99286004)(65806001)(14454004)(186003)(66066001)(6436002)(99936001)(486006)(2616005)(39060400002)(85202003)(71190400001)(316002)(6246003)(65956001)(52116002)(58126008)(71200400001)(6306002)(6512007)(476003)(3846002)(6116002)(110136005)(53936002)(31696002)(2906002)(7736002)(66574009)(85182001)(53546011)(6506007)(386003)(76176011)(102836004)(31686004)(229853002)(81156014)(5660300001)(8936002)(14444005)(65826007)(256004)(68736007)(8676002)(3260700006)(64126003)(478600001)(25786009)(81166006)(2900100001)(36756003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2751; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gb6zaSB2zec0BQkFSc/JF+Ih5fGaalaNZ71xJX2d12RI9Zex5OAkheItX/eSpdD4jNdf2WAzvbdVBnYGBrTtAOVxt7dkzZ/pVP+OikU0xODBuJh2K41yt4Vc4dVnRTOXF3OcjjBynGuLZ3nEC743dnTMP/K+UObLKFGExOl2ur+BT0MLy7x1f1werhD9ySYDEb8Tuwy7DH09KSjnR4WCtl8/kHFRvBtAs93rGvrAfsr4rUtCQQ8L3eVyv5Shsh3djkkZxyNdAB6g+1qPecLFfaRzMm/JYl8UFCellNnUzDyTQfp9NOxvHit9vLr/A7LJmmt/zkCffuFZrocp/0gn0o3fKuGqaCqb70x2aDx2wuQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060708060603040900010207"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 90e70861-8f6b-416e-fcbd-08d6496c8875
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2018 13:33:01.9702 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2751
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSSUxTURSGvX2vA40ljwpyrFNodKECMonFgcG4wESRJSlBKPBCy9CSVyQF TKxiFBmUhYQpWgiDBBwIEJEEI4USpUwFRyZNhRQpKmEhBREi7QVj4u4758//nz83l0cIZ9ki nkKZQTNKWaqYwyfLo9o1XndHrdE+QzqRpDWvmSOZvl/FluhGrrElb1/9ZoWS4R0VU9zwG4bv 7PDa2hVWJCHln0qkUxWZNHM0OI4vX7N8RunD2Rrjoo6rRcPyfMTjARUAdbMu+YjPE1IGBCu2 SU4+ctoYlhBUjmVioZYF/f02wi6QVDEBq+1iLJSywDYyxMWDBUHVswqHnUOdhVs/XrLs7Erd QWDsirWf20F5QdvTSLz2hoaBGXKLS6xFbHzgICys9yE7C6gQMNdNEDjfxoKuUYujhRN1Ecr1 nY58RO0Em/GRgwnKHcZndA4GyhXMI/0czG4wN73OxiyGMus4297HjYoB/fUQez5QZQh+fisl ceYl6PyUt+n1hMEPMwjzXhjVFSBs+MiBodrBTeECvOnL42JhEkH7UtNft6mnarORCnKnbm62 2AeNRWayGPlU/FMc820EZUZFheMFXKCvfIbE+0B40GomMB+B+up54n/vSSj7pedg9oB7BWYu 5mMw37uIMPtD/ZM1ThXiNyI3Na2OT0vy8/OmGUWCWq1SeivpjBa08eX0bas+z9HcbFg3onhI vF0w32SNFrJlmeqstG50YCPnS3OTCYlIpUpJi10FHQEbsiBRlpVNM6pY5nIqre5Gu3mk2F0g iWiVCqkkWQadQtPpNLOlsnhOIi06b5pYzvKN8nrcID13Oudqjo/KcKhF7/xOG+rr/Lo3aLVy IGxwwv+hV+7y3PRAg9zpvqG6Js2ijSuskZZqF/ZnLCe/D9Ioqo2B/K/znmNNYb7CFyWrFuue ZNOZbRGaBFF0MNObqBlLOX5F6bJm8hgRL/VMe7gUSnediM9l3FQxYlItl/keJhi17A+umTcM egMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/OkfD3MRm1upCfnWQTHXUp_hh6MM>
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2018 13:33:10 -0000

Hello,

In some cases I want a percentage without fractions. This could be 
defined using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in 
the range's argument.

     typedef percent-short {
       type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out all the 101 integer values :-)
     }

regards Balazs

On 2018. 11. 07. 9:34, Juergen Schoenwaelder wrote:
> On Wed, Nov 07, 2018 at 07:49:54AM +0000, Yemin (Amy) wrote:
>
>> For the range, if the defintion can cover the our range(0..99.9999),
>> it will be acceptable.  In your suggestion below, does that mean the
>> base defintion is without range, while refined types can chosse the
>> range they like?
> I was thinking loud. Let me detail somewhat more what was going on in
> my head:
>
>    We could define a percent type without the upper bound being
>    whatever the decimal covers but fixing the precision of the
>    fractional part. We could then narrow the upper bound via
>    subtyping:
>
>       typedef percent {
>         type decimal {
>           fraction-digits 4;
>           range "0..max";
>         }
>       }
>
>       typedef percent' {
>         type percent { range 0..100; }
>       }
>
>    If wanted flexibility on the fractional part, we could define
>    percent with a fixed range and the largest number of fraction digits
>    possible and then we could subtype this to obtain a precision that
>    makes sense in the usage contexts (although it is not clear whether
>    YANG 1.1 really allows this, if not this may be just due to nobody
>    ever thinking about this before):
>
>      typedef percent {
>        type decimal {
>          fraction-digits 16;
>          range 0..100;
>        }
>      }
>
>      typedef percent' {
>        type percent { fraction-digits 4; }
>      }
>
>    An ideal solution would provide flexibility both on the range and
>    the number of fraction digits but it seems this is impossible since
>    these two properties (range and precision) interact.
>
> So it seems we have to do something that is pragmatic and this likely
> means fixing the fraction since subtyping the fractional part may not
> be allowed by YANG or not be supported by implementations. The
> question is then how we pick suitable fractions. I understand you want
> 4 digits.
>
> /js
>
>> BR,
>> Amy
>> ________________________________________
>> 发件人: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de]
>> 发送时间: 2018年11月6日 22:16
>> 收件人: Yemin (Amy)
>> 抄送: Qin Wu; Xufeng Liu; balazs.lengyel@ericsson.com; NETMOD WG
>> 主题: Re: [netmod] for a future rfc6991bis
>>
>> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
>> which is likely not generally useful. In fact, even 150% can be in
>> some contexts a perfectly sensible percentage. So we may need to
>> provide some flexibility here, i.e., having a base time where the
>> range can be refined and refined types with an upper limit set to 100%
>> for use in situations where this limit is sensible.
>>
>> The more difficult aspect seems to be precision, I am not sure YANG
>> allows subtyping the fractional part. RFC 7950 seems to be silent
>> about this and in the general case this would not be meaningful. But
>> in this particular case, when the number range is limited, it would
>> actually be OK to allow this (but then we have to have a limit and
>> we can't set the upper limit to max).
>>
>> /js
>>
>> On Tue, Nov 06, 2018 at 02:21:33AM +0000, Yemin (Amy) wrote:
>>> If the percentage is defined as following, as a author of draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
>>> But it's better to include in RFC6991bis, as percentage is a generic and widely used item.
>>>
>>> BR,
>>> Amy
>>> ________________________________
>>> 发件人: netmod [netmod-bounces@ietf.org] 代表 Qin Wu [bill.wu@huawei.com]
>>> 发送时间: 2018年11月6日 9:25
>>> 收件人: Xufeng Liu; balazs.lengyel@ericsson.com
>>> 抄送: NETMOD WG
>>> 主题: Re: [netmod] for a future rfc6991bis
>>>
>>>
>>> Another case would be :
>>>
>>>
>>> “
>>>
>>> typedef percentage {
>>>
>>>        type decimal64 {
>>>
>>>           fraction-digits 5;
>>>
>>>           range "0..100";
>>>
>>>       }
>>>
>>>     description "Percentage.";
>>>     }
>>> ”
>>> Which is defined ietf-connectionless-oam.yang module.
>>>
>>> -Qin
>>> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Xufeng Liu
>>> 发送时间: 2018年11月6日 3:49
>>> 收件人: balazs.lengyel@ericsson.com
>>> 抄送: NETMOD WG <netmod@ietf.org>;
>>> 主题: Re: [netmod] for a future rfc6991bis
>>>
>>> The draft that asked for the percentage type is: https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02
>>>
>>> They currently define:
>>>
>>>                leaf availability {
>>>                  type decimal64 {
>>>                    fraction-digits 4;
>>>                    range "0..99.9999";
>>>                  }
>>>                  description "Availability level of the link";
>>>                }
>>>
>>> Thanks,
>>> - Xufeng
>>>
>>> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote:
>>>
>>> +1 to percentage.
>>>
>>> Balazs
>>> On 2018. 11. 03. 3:44, Xufeng Liu wrote:
>>> Remember that some draft asked for a type of percentage value to the nearest hundredth. Wondering if it can be put in.
>>>
>>> Thanks,
>>> - Xufeng
>>>
>>> On Fri, Nov 2, 2018 at 11:39 AM tom petch <ietfc@btconnect.com<mailto:ietfc@btconnect.com>> wrote:
>>> ---- Original Message -----
>>> From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>>
>>> To: "Kent Watsen" <kwatsen@juniper.net<mailto:kwatsen@juniper..net>>
>>> Cc: <netmod@ietf.org<mailto:netmod@ietf.org>>
>>> Sent: Tuesday, October 30, 2018 10:14 AM
>>>
>>>> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
>>>>>>> In addition, it might be good to introduce [inet?] types for RFC
>>> 5322
>>>>>>> (Internet Message Format) including perhaps:
>>>>>>>
>>>>>>>    - email-address        (addr-spec, per Section 3.4.1)
>>>>>>>    - named-email-address  (name-addr, per Section 3.4)
>>>>>>>
>>>>>> Where are these used? Or have these already been used somewhere?
>>>>> I'm unaware of these ever having been used before.  I am working on
>>> a private module for which I want to configure an email address.  After
>>> some searching, I concluded that no such types have been defined, and
>>> thus thought that they might be good candidates for addition.
>>>
>>>
>>> We could defined a user-name, of the form localpart@domainpart as is
>>> widely used to identify a user in operations but which does not, in my
>>> experience, owe anything to i18n, just a straightforward character set;
>>> yes it would not boil the ocean, but could be useful.  I am surprised
>>> not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
>>>
>>> Tom Petch
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> It would be good to have strong use cases. I fear that defining this
>>>> type won't be easy given that we also have internationalized email
>>>> addresses (RFC 6530 provides an overview) and we might have to create
>>>> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>>>>
>>>> /js
>>>>
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>> _______________________________________________
>>>
>>> netmod mailing list
>>>
>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>>
>>> https://www.ietf.org/mailman/listinfo/netmod<UrlBlockedError.aspx>
>>>
>>> --
>>>
>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>
>>> Senior Specialist
>>>
>>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com<mailto:Balazs.Lengyel@ericsson.com>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com