[kitten] Service discovery URI field case-sensitivity

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] Service discovery URI field case-sensitivity

Matt Rogers
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Service discovery URI field case-sensitivity

Greg Hudson
On 10/12/2016 04:46 PM, Matt Rogers wrote:
> 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.

This is in reference to draft-mccallum-kitten-krb-service-discovery-03.

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

Our scheme, "krb5srv"?  Formally, I'm not sure if we have to specify
that when defining a new scheme, but informally we should recommend that
URI record processing code match the scheme case-insensitively.

The scheme in the transport-info for kkdcp should also be matched
case-insensitively, of course.

> 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.

Agreed.  It's unlikely that we will ever add a second flag; it's
vanishingly unlikely that we will need more than 26 (or 36 with digits,
or whatever).

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] Service discovery URI field case-sensitivity

Petr Spacek
On 13.10.2016 17:28, Greg Hudson wrote:

> On 10/12/2016 04:46 PM, Matt Rogers wrote:
>> 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.
>
> This is in reference to draft-mccallum-kitten-krb-service-discovery-03.
>
>> First I believe the scheme should be case-insensitive per BCP 35 advice
>> on URI scheme values.
>
> Our scheme, "krb5srv"?  Formally, I'm not sure if we have to specify
> that when defining a new scheme, but informally we should recommend that
> URI record processing code match the scheme case-insensitively.
>
> The scheme in the transport-info for kkdcp should also be matched
> case-insensitively, of course.
>
>> 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.
>
> Agreed.  It's unlikely that we will ever add a second flag; it's
> vanishingly unlikely that we will need more than 26 (or 36 with digits,
> or whatever).

I'm okay with this proposal. Take my previous notes on case sensitivity just
as wondering out loud.

--
Petr^2 Spacek

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten