[kitten] Service discovery URI field case-sensitivity

Matt Rogers <mrogers@redhat.com> Wed, 12 October 2016 20:46 UTC

Return-Path: <mrogers@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B07129675 for <kitten@ietfa.amsl.com>; Wed, 12 Oct 2016 13:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.918
X-Spam-Level:
X-Spam-Status: No, score=-9.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 T203t21lYZXm for <kitten@ietfa.amsl.com>; Wed, 12 Oct 2016 13:46:56 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462FF129673 for <kitten@ietf.org>; Wed, 12 Oct 2016 13:46:56 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A708EC04B928 for <kitten@ietf.org>; Wed, 12 Oct 2016 20:46:55 +0000 (UTC)
Received: from vpn-58-163.rdu2.redhat.com (vpn-58-163.rdu2.redhat.com [10.10.58.163]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9CKksqO000651 for <kitten@ietf.org>; Wed, 12 Oct 2016 16:46:55 -0400
Message-ID: <1476305214.14318.20.camel@redhat.com>
From: Matt Rogers <mrogers@redhat.com>
To: kitten@ietf.org
Date: Wed, 12 Oct 2016 16:46:54 -0400
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 12 Oct 2016 20:46:55 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/PyP-1TiTksmT9axybrD-VaVXy0Q>
Subject: [kitten] Service discovery URI field case-sensitivity
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2016 20:46:58 -0000

The service discovery draft needs some clarification of the encoding
and case sensitivity for the URI field values, and I have heard some
different views on how they should be defined. 

First I believe the scheme should be case-insensitive per BCP 35 advice
on URI scheme values. 

Flags, if specified as case-sensitive would allow more flag values at
the expense of some possible operator confusion (however, the values
will be IANA registered and a valid character range specified).
Transport type values will also be IANA registered and case-sensitivity 
would not gain us anything here. These fields are currently case-
insensitive in the MIT krb5 implementation.

Transport info field can have both case-sensitive and case-insensitive
elements as defined by the transport, like the KKDCP path and hostname.
MIT krb5 treats KKDCP URLs in this respect.

Overall my preference would be to define in their respective sections,
the scheme, flags, and transport-type fields as case-insensitive and
say the transport-info field's case rules are to determined by the
transport specification.  Although this limits the flags, If we really
ran out of flags in the future then the document could be updated.

Regards,
Matt