Re: [Last-Call] [art] Artart last call review of draft-ietf-core-problem-details-05
"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 30 June 2022 07:34 UTC
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D602C15AAC5; Thu, 30 Jun 2022 00:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.787
X-Spam-Level:
X-Spam-Status: No, score=-3.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xhu0Nku9wjqm; Thu, 30 Jun 2022 00:34:49 -0700 (PDT)
Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01on2107.outbound.protection.outlook.com [40.107.113.107]) (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 634C3C14F74D; Thu, 30 Jun 2022 00:34:47 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gVS9DMDTXyhYVz/+yq3GFzTjXFiUJIxX1i69Hllnzco16CB4RE6EeBsiU45Fnw+Bjx2qD+Jjts4nhX3mjD2Btfp/ajyJSSXhyilmFIGdNbPboDAWEmSzh4WdwSQwqCeDAebY9Cxs5PXmhNIe6tGXT18f9J/29WKUhqXCIfD0ZKiPMJgenWWPIi5HlOi+18GG9SdA8RjblIEjUs2hT9G5uskXiuGEwwxWgrzqzrlTYwu8VKAix+dCVERCIrhg/7CrruLSmy8oQiQvRTlPXVVwRVgTIgxRd1sl73UZwC+GZMksQTt+Zs5OOQ1jPGoLoYIMORLdrDgIUVFalFLHgyNjCQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+ASUSK7Vz8Ugf8g3mvDLPJSwUEpn6kSLzn7tkl7AE6c=; b=J6O7R3miWhZZa2i8YZWfbk9E0bjKNEt2CrQMfDWWsQDtljUa19bIU+wcWU3OOjtZz8WTz5Ij4Nnv3zDdfVay07V1IG94sRYhT9N6AqQa1c3d4I7JKVUHEZdXkZblhJObmhOAtZMnPfWyppBscnbJhPXASDCE6/b+ImNyqUf8AI2El9P90qsModv02l+mjpYca/gkxRFWNtlac5H66n7T5SAQLPyxs/esSi+TIwED9dyJ0fWzlysi07ts0DgQBWuYGmhNqzJA9xM9uI97k1qlHA1SiuelNI2L9OBnZas7iqUT2hkQdjZ5C2m2xGgsFtHnqS0loOu/FCkG3zpn5KmgRw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+ASUSK7Vz8Ugf8g3mvDLPJSwUEpn6kSLzn7tkl7AE6c=; b=EbHsLZ/Gi/dgckbEqhLKY2My8HldLcwFb7J9QFHcwGxcy0mvxmvRSuJ5/U+5IpvxJUlDmo6/lXh0vDHoVFhRG25FyAqk3VrWWz+wNzpgeiI2K7+SQW9ioP5vNan0AeaEDMXyBjLfPu3Yc3m2JxHzHw7WUlguQqeZ7enPZkDh0Xk=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp;
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by OSAPR01MB2065.jpnprd01.prod.outlook.com (2603:1096:603:1a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5373.17; Thu, 30 Jun 2022 07:34:42 +0000
Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::2874:1f38:b58e:4695]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::2874:1f38:b58e:4695%5]) with mapi id 15.20.5395.014; Thu, 30 Jun 2022 07:34:42 +0000
Message-ID: <295a0593-85f6-753e-0572-31a3af63012b@it.aoyama.ac.jp>
Date: Thu, 30 Jun 2022 16:34:41 +0900
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Carsten Bormann <cabo@tzi.org>
Cc: Harald Alvestrand <harald@alvestrand.no>, Applications and Real-Time Area Discussion <art@ietf.org>, Core WG mailing list <core@ietf.org>, draft-ietf-core-problem-details.all@ietf.org, last-call@ietf.org
References: <165511479760.19573.12671700576299137749@ietfa.amsl.com> <63D13796-758D-469B-AFA8-3050C9F87819@tzi.org> <dde9d36c-61e5-afcc-e15a-787c99d5fba9@it.aoyama.ac.jp> <0012F049-354A-4450-B923-857D24AB9459@tzi.org> <90b785ef-934b-da9d-7d89-7018bdebbb75@it.aoyama.ac.jp> <B96E980A-72E3-4678-B214-8464958845BB@tzi.org> <ff5f8ff1-67fc-eead-6b38-62c8d64ebf45@it.aoyama.ac.jp> <4207E390-270A-463B-A38A-063AD2436370@tzi.org> <e05dd15e-c66a-1a13-80f3-5b46bf9bab08@it.aoyama.ac.jp> <1E366CDD-2CB9-4AED-A386-67F2BC426B21@tzi.org>
From: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
In-Reply-To: <1E366CDD-2CB9-4AED-A386-67F2BC426B21@tzi.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: TYCPR01CA0026.jpnprd01.prod.outlook.com (2603:1096:405:1::14) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: b53d0db6-e436-4465-1c73-08da5a6aff29
X-MS-TrafficTypeDiagnostic: OSAPR01MB2065:EE_
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: LnDA2Bg+BE7J7l0Pj/r8M+wD1zztFS5tl9keLVNQn4F5tnZcyId6+2xW3NJMSjcoLSynvzBanvVQbJXlp14MDRyWqSpEUv69qUGFaQZwGf/4xiCnF7pHYZyO2a5Dsu+bFcazc2Y7Gaq2nDviwQYMSGY4YYCqWJthPFb1HAt8G4hYZ8K/bPe3A2MylGwB0KN5vMIT+Pqw31sBoE6NRN92oKrIetXEzPTxFXZDuyxKaPyIA3mSTYtPaQHwlIymD+RVc+Cx6GeqHcELis6nle2VAuZlnJwHb4h+N9ruYuNGv5TNxW7a5zKkdA+yCU94tkwoxSEG0UUovXDSLmYyHLqyF8T6QuUp+o5ALL2XUG22HFyidnmIEd13blg2gtyhZTLWYC9dZEfM+5viftyUhTPMM503sCX8WmTcCPEX5zXJl/YV/5WMsD4LlK6wOPYEie9Q15uSCURrzCz4JgIdhKkgpYphmbt78Iz4ezG0lE0bWWYFk8MqDi9+IeQNp9q7eBUjnK/g1rITs2IH3/pGDpRPxXHMGLBM3MLSxbYLhMwlnPPTrMAdW6me/RXUSeE/D0oLVE96q9YMNDMUey5SEJb375VDeWUr+ugZLs/+44Zp2m2JUsWrbuiC8fMgfiMXQFDJbFquY//VwwV/vD0oQSKCxJUNtUOJHMv6Z0TG10wXBwNgHqEmwJ8ah743/q3Dm6FREWl/Vsl63sKHzEejvZ1jXLzSOXh5GPfYPqWStrVU96kN/7+OUIqVT+7wF0ut/jJe9o1KdFaK50bzC8tV4cX43otZzu7F5tIU2BAxR98RinpJwi5INcVXm6eJPIEe9RbZ9h+R/Eu9wJ0C0XY1DCbc8TSbMvd4SeNsS84SH9K3rWEDp+VSk9BrfFghR/XSSueGrUng22hLlaBRL6MvlGPoNbnHj9dkOeCPzQS5Kd9xGww=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(376002)(366004)(346002)(396003)(136003)(39850400004)(8676002)(4326008)(66476007)(66946007)(66556008)(83380400001)(54906003)(6916009)(316002)(41300700001)(2906002)(5660300002)(966005)(8936002)(478600001)(6486002)(31696002)(31686004)(86362001)(2616005)(26005)(786003)(6512007)(52116002)(36916002)(6506007)(53546011)(41320700001)(186003)(38350700002)(38100700002)(43740500002)(45980500001); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 1otrbNv77EKyz/osqW3zmC3ha2J1cJSH+x0LXcvxSpqtPsbFcIzo7Ghuf/eqmEs1N5QAagYsSKyOeb5MvJsgeyvY56uNo0iEO1Nx3RsZ2UdGOpvSAbnX8foBc8c2Vc5bj6kH+uqqDuTf6y/oTzsoZbbt6bMZUFjLEbwSLt5Dr6OlAYSXtVN1rnCOT7LPGw1i19phpBXc9k6URDxKaf7FvsBn66DPR/jxmW85TynOdE0mu2Y6Ue35Lmj4PUTQcdbQWXy1UQTEAwprh4pk9H41LW1dBVapOYJ58VmEAv++ncVooiCfOjTjwqOdv5gePzwJSW9PeGtf+EFjkdXPUVWKxCRJW5qlw2hq/q/2Mht/ZML4IifBz1C4lgLhggFjWWvUlrbnZ+PnmMnatHpqVQsGbLwUdpwWwsEzAYKvzeyDpw208WTC3aoX3acrCOVzGKe7uqUNG/9AS4fLZbxv8aY7rEkdVi0A5XbKP2HkXmJTVRC0vgQ0hkVNIAWglwNr6l3LpZoYYks+pG3YxFbIL++Lkc5b1TgQ8X/JqpzqgzR9DvWubeJybzvfp1Uvhdc16f0yCnEUPltSldbz8uBD15WFbxV2YDIZ1C7yupmh2Ph2f5vvB5ZCyXPmTIZNPt+8hI9kTW8dT/p65SLoq4/RUXfHhwumOKSRU7ryqxUFWx9N+kmi8ZUIzXFIyPAf8b1LD4VyGuEcUkrf2T4q0qOE9wHP1ewlPwjFiQIZDmKvQr5bMBUa2LSrcbJt7tEOb9ZWcMFAEFFzlcv4ugd77NE+xv6515XTr3anv6UtBCJ9SDNeTGrOu9tnnmFiZDpiN/11ArTv/sen1jg5TkIq0eLL7vMGhMiURdHT3UTTUAV8GxS8ASsiJyPRQay4i4RhCihRWF4Y+F1iXryZr3H0I9afIFNCYH+VG8c6JxnyR/VsYPGzdtEy83KNK+OB1ZENk8HBvTBKZjigCdHldpT1tiVDSNxbaav6dkUZWSWZVzM/5by6/cFhjLUQm3FBBmFtqdVBKXUeu9NXX+80DrKFJnp8CQE4dp5yByF5AUfGXDJF1eGZ1+OdVeOArnbKMPHVXNY5gf9Ei/PIMxb/1AyLcdLuGaG44zAB4tmnXIRKSdMBQlxTWAa9U7utsD+wYcOfexZ32vDSkXxQcooHuDDjU4RILSF8UIIsm3T4JobMj3ieomcZsS/s2I1wiyGM3Mj4tYzl+ToTgcFxOnmJeTdd8HdyeotKtpP7kF9eVgBCgd5z94CHYaFkniHgxRqFC/r3qAKhSb39Xk6McJxTOkwBtbGi7yuXZAUnh5alGWJr+1YvsrI3VYQ8lzQQpUAaZYamA7Akz9Cjb+SANN/WT+ntPsPh4/14K6Us6q+ZpRLdRxe90K6QJ7kn2Z/5ZxG2Q5QcW+1a/l1I4mZryYTQMz3fd7UL5jBl0FZ7FxW2dX75zntzf2/O5KBmfUsg64JumgwdF2UGBpyfqd3nMCSOatomrW4PawgKIjMJb1P1xmJGkb4ytUIFdMoKBIMMc23C7wQmQ6iYWCLkOTTJOe2vRKCudeP1pzMx0hHkRGRdXk3WXfISF6CCUZinMJAHl8Bezf02foI5l7kIM5+ahCaCEiW4jn9AWY89hw==
X-OriginatorOrg: it.aoyama.ac.jp
X-MS-Exchange-CrossTenant-Network-Message-Id: b53d0db6-e436-4465-1c73-08da5a6aff29
X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2022 07:34:42.1357 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /XA1vNgbKyy6dJo28+NuylFOtceBIFxMVq/ERTTIsAlkRE5jyxcyskRyW5z/zDGQFpw8bh9ilYUc6WSb0MElDA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB2065
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/Jxz5IZ9Hh154jOkYh4LqXyb6C_Q>
Subject: Re: [Last-Call] [art] Artart last call review of draft-ietf-core-problem-details-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jun 2022 07:34:51 -0000
Hello Carsten, Glad to see lots of progress, both in the draft and in our mutual understanding. As our fields of expertise are not very close, this indeed requires quite some work :-(. On 2022-06-30 00:40, Carsten Bormann wrote: > Hi Martin, > > thank you for your further explanations. >>>>> Base-rtl and base-lang are specified to apply to unadorned (non-tag-38) strings. >>>>> It is not defined in the current text whether an implementation would apply base-rtl to tag-38 strings with absent directionality. >>>> >>>> I think it's bad practice to leave things like this open. The only result it can produce is confusion, and nobody benefits from that. Why not just say that base-rtl and base-lang apply if language or direction are missing on a tag-38? >>> Because tag 38 operates independent from the enclosing problem-details document. >>> It needs to be possible to implement tag 38 in its own library. >>> If that happens to have a way to supply default parameters, these could be taken from base-rtl/-lang in the calling problem-details implementation. >> >> There's really no point in going halfway in specifying bidi for problem details. What you want is that senders (e.g. servers sending a problem detail; ultimately programmers/translators that prepared the text(s) in that problem detail) have the confidence that the text(s) they prepared get displayed the way they intended so the reader on the client side will understand them without having to guess what was messed up. > > If the generator knows what it wants, it can set ltr/rtl, that is easy. > The hard part is what it can do when it doesn’t. The question here is who the 'generator' is. In my understanding, human readable text is produced, at least initially, by humans. The way humans work is to type text, look at how it displays, and intervene when they are not happy with the display order. Intervening means setting the (base) directionality of the text (snippet) in question to a specific directionality. Not intervening means being okay with the implicitly detected (base) directionality. That implicit detection in the bidi algorithm is exactly the same as "first strong". > Not specifying directionality (absent third element) is one way; the data item generator by this essentially leaves everything to the data item consumer. Note that this allows that the consumer can be wiser than the generator; having the generator dictate what the consumer must do in this case is counterproductive. > > For the consumer, we do suggest defaulting absent to “auto” if no other context is available. > > Explicit null (“auto”), again, means that the generator does not know enough to set ltr/rtl; but it does know that any additional context in the data item won’t help (e.g., because the controlled text is imported from a different environment than the text in the rest of the data item). > Here again, asking the generator to specify something it doesn’t know does not make sense. > > The FSI..PDI suggestion is just a suggestion, “auto” does not “mean” FSI. > (If the generator knows the directionality of the text, it’ll set rtl or ltr and not auto.) You may argue this “leaves things open”, I would argue that this is the case where there isn’t enough information on the generator side to nail anything down. It seems to me that your model of 'generator' is some automatic text generation. Mine is a human writer or translator. (Except for the special case of a blind person,) they will judge whether directionality is okay or not visually. >> An implementation of tag 38 "in its own library" will most probably come with a way to supply a default parameter; otherwise, the implementers haven't really read the spec. > > Yes. > >> Of course there will be implementations on constrained devices that completely ignore directionality because they are not intended for the Middle-Eastern market. They will not contain fonts for Arabic or Hebrew either, and that's just fine, but a separate consideration. > > Indeed, that is the problem — but one interesting case is where the constrained device doesn’t know much, the less-constrained correspondent does. The objective here is to make these asymmetric situations work. The text in question somehow must have gotten into the constrained device in the first place. In that case (and absent bad engineering which is always a possibility), it will have come with the relevant directionality information. It's clear that a constrained device cannot come with some very smart AI heuristics to fix up directionality, but neither is a more powerful device supposed to do so, nor guaranteed to get it right if it does so. So to me the distinction between constrained devices and less-constrained devices doesn't seem to help here. (I'm sure there are quite a few other cases where it makes a lot of sense.) >> I agree that there are other "auto" algorithms, but they are really, really not popular. The only "auto" algorithm that TR #9 uses is first strong (as already explained in detail in an earlier mail, see below). It's also the easiest to implement, in particular on constrained devices. > > You are comparing general algorithms. But one of the two peers might know more and be able to apply that knowledge. The current text for “auto” is designed to allow this. Can you give an example of what you mean by "might know more"? My understanding is still that the original writer/translator must know best, the machines in the middle, whether very simple and small or very powerful, don't know anything at all, and the recipient reader shouldn't have to guess or 'know'. >> If you want some background for implementers, which I think is a reasonable concern, then there are other documents better suited than STRING-META (which is mainly for spec writers). >> >> A quick search on https://www.w3.org/International/ brought up e.g. the following: >> https://www.w3.org/International/articles/strings-and-bidi/ >> https://www.w3.org/International/articles/lang-bidi-use-cases/ >> https://www.w3.org/International/articles/inline-bidi-markup/uba-basics >> But there might be even better resources. > > Thank you for the pointers. I’m planning to make a PR to draft-bormann-cbor-notable-tags. > The notable-tags draft is intended to explain more about usage and implementation of certain tags, including when to choose which. > It is probably a better place to include pointers to knowledge that is still growing, so I would expect us to direct further work there. Sounds reasonable. Maybe it may make sense to, in the long term, move the definition of tag 38 from problem-details to this draft. Anyway, please give me (and the relevant lists!) a heads up when you have a new version with some relevant text. Regards, Martin.
- [Last-Call] Artart last call review of draft-ietf… Harald Alvestrand via Datatracker
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … Francesca Palombini
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Ira McDonald
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … Ira McDonald
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … Ira McDonald
- Re: [Last-Call] [art] Artart last call review of … John C Klensin
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … tom petch
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … tom petch
- Re: [Last-Call] [art] Artart last call review of … Ira McDonald
- Re: [Last-Call] [art] Artart last call review of … tom petch
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Harald Alvestrand
- Re: [Last-Call] [art] Artart last call review of … John C Klensin
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … John C Klensin
- Re: [Last-Call] [art] Artart last call review of … John C Klensin
- Re: [Last-Call] [art] Artart last call review of … tom petch
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … John C Klensin
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- [Last-Call] Thank you! -- Re: [core] [art] Artart… Carsten Bormann
- Re: [Last-Call] Thank you! -- Re: [core] [art] Ar… Francesca Palombini
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- [Last-Call] Language tags and YANG Francesca Palombini
- Re: [Last-Call] [art] Artart last call review of … Carsten Bormann
- Re: [Last-Call] [core] [art] Artart last call rev… Thomas Fossati
- [Last-Call] Call for comments on draft-ietf-core-… Francesca Palombini
- Re: [Last-Call] Call for comments on draft-ietf-c… Marco Tiloca
- Re: [Last-Call] [core] [art] Artart last call rev… John C Klensin
- Re: [Last-Call] [core] [art] Artart last call rev… Carsten Bormann
- Re: [Last-Call] [core] [art] Artart last call rev… John C Klensin
- Re: [Last-Call] [art] Artart last call review of … Martin J. Dürst
- Re: [Last-Call] [core] Call for comments on draft… Ari Keränen
- Re: [Last-Call] [core] [art] Artart last call rev… Thomas Fossati
- Re: [Last-Call] [core] [art] Artart last call rev… Carsten Bormann
- Re: [Last-Call] Language tags and YANG tom petch
- Re: [Last-Call] Language tags and YANG Carsten Bormann
- Re: [Last-Call] Call for comments on draft-ietf-c… tom petch
- Re: [Last-Call] Call for comments on draft-ietf-c… Carsten Bormann
- Re: [Last-Call] [core] [art] Artart last call rev… Francesca Palombini
- Re: [Last-Call] Call for comments on draft-ietf-c… Francesca Palombini
- Re: [Last-Call] [core] [art] Artart last call rev… Carsten Bormann
- Re: [Last-Call] [core] [art] Artart last call rev… Carsten Bormann
- Re: [Last-Call] Call for comments on draft-ietf-c… Randy Presuhn
- Re: [Last-Call] [core] Call for comments on draft… Carsten Bormann
- Re: [Last-Call] [art] Call for comments on draft-… Martin J. Dürst
- Re: [Last-Call] Language tags and YANG Martin J. Dürst
- Re: [Last-Call] [art] Call for comments on draft-… tom petch
- Re: [Last-Call] Language tags and YANG tom petch
- Re: [Last-Call] [art] Call for comments on draft-… Carsten Bormann
- Re: [Last-Call] [core] [art] Artart last call rev… Thomas Fossati
- Re: [Last-Call] [core] Call for comments on draft… Hubert Przybysz
- Re: [Last-Call] [core] [art] Artart last call rev… Francesca Palombini
- Re: [Last-Call] [art] [core] Artart last call rev… Carsten Bormann
- Re: [Last-Call] [art] [core] Artart last call rev… Martin J. Dürst
- Re: [Last-Call] [art] [core] Artart last call rev… Carsten Bormann
- Re: [Last-Call] [art] [core] Artart last call rev… Carsten Bormann
- Re: [Last-Call] [art] [core] Artart last call rev… Martin J. Dürst
- Re: [Last-Call] Call for comments on draft-ietf-c… Francesca Palombini