IETF Logo Mail Archive

Re: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-16.txt

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 17 March 2016 20:07 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: mile@ietfa.amsl.com
Delivered-To: mile@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDF412DA98 for <mile@ietfa.amsl.com>; Thu, 17 Mar 2016 13:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 8lsQKJcC886m for <mile@ietfa.amsl.com>; Thu, 17 Mar 2016 13:07:00 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8364B12DA72 for <mile@ietf.org>; Thu, 17 Mar 2016 13:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1458245219; d=isode.com; s=selector; i=@isode.com; bh=I2grzrwT4hIahb5FoRcn/fNytTbUbzyoXduAJLxD9hw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cRijqD5OKO7YBIbrhZfX8xkwIGZBBsUFM3EomyYRAkSjRUT5gqx82Yox1dNQAzk4HBHe0k A2z+zOwoCpp4FrWXv/NYVgRcZQCGrN6r39fKveRTTA1W2h0ZD2Bi0BO/gi3ox4i81JD8ZZ hMqpZzAQFoZmRXZ+DS2J59UvuR9AEV8=;
Received: from [192.168.0.6] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <VusOYgB25ohA@statler.isode.com>; Thu, 17 Mar 2016 20:06:59 +0000
X-SMTP-Protocol-Errors: PIPELINING
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (13D15)
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFCD96E9730@marathon>
Date: Thu, 17 Mar 2016 20:12:53 +0000
Message-Id: <7441961B-C109-4E7D-A8C9-013ABC043650@isode.com>
References: <20160201220552.16506.51013.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFCD969F185@marathon> <DBCB2C3E-1AF3-44EB-BBF5-A3B0A46CAF96@isode.com> <56BE0D04.5090307@isode.com> <359EC4B99E040048A7131E0F4E113AFCD96E9730@marathon>
To: "Roman D. Danyliw" <rdd@cert.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/mile/Ij0bpVeASd6OIcpqlQgZsl68AUM>
Cc: "mile@ietf.org" <mile@ietf.org>
Subject: Re: [mile] I-D Action: draft-ietf-mile-rfc5070-bis-16.txt
X-BeenThere: mile@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" <mile.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mile>, <mailto:mile-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mile/>
List-Post: <mailto:mile@ietf.org>
List-Help: <mailto:mile-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mile>, <mailto:mile-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2016 20:07:02 -0000

Hi Roman,

On 17 Mar 2016, at 19:12, Roman D. Danyliw <rdd@cert.org> wrote:

>> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]
>> 
>> In 2.17:
>> 
>> formatid might need a bit more details. Can you provide some examples?
> 
> This @formatid is a holdover from the original RFC5070.  It is an opaque identifier that an implementer could use to provide guidance on how to parse this extension.
> 
> I'm struggling to come up with a good use case, but it would work as follows:
> 
> <Extension name="custom field1" dtype="string" meaning="explanation1" formatid="string-type1">
> <Extension name="custom field2" dtype="string" meaning="explanation2" formatid="string-type2">
> 
> The parser would know to process "custom field1" as a "string-type1" and "custom field 2" as a "string-type2".
> 
> Why the format information couldn't be inferred from @name assuming they are uniquely assigned; or an enumerated value set with @ext-dtype="string-type1 or string-type2" isn't clear.  
> 
> Remove?

I think either remove or add text (at least examples) to make this implementable from the document.

Best Regards,
Alexey

v2.23.0 | Report a Bug | By Email