On Thu, May 20, 2021 at 04:15:27PM -0700, Nick Harper wrote:
> > But, it makes for a fairly terrible user interface for the human
> > operator. Compare:
> >
> > * managesieve
> > * 6d616e6167657369657665
> >
> > Typos in hex values are easy to make and hard to recognise.
>
> I agree that
On Thu, May 20, 2021 at 3:56 PM Viktor Dukhovni
wrote:
> I agree it is a straight-forwarding encoding for machines, and it is
> well suited for the GREASE code points.
>
> But, it makes for a fairly terrible user interface for the human
> operator. Compare:
>
> * managesieve
> * 6d616e61
On Thu, May 20, 2021 at 11:52:50AM -0700, Nick Harper wrote:
> > Since the likelihood of actually adding exotic ALPN values to the
> > registry appears slim, why not say so. That would leave the exotic
> > values for private on-the-wire use, while allowing DNS and other
> > configuration serialis
On Thu, May 20, 2021 at 11:19 AM Viktor Dukhovni
wrote:
> On Thu, May 20, 2021 at 01:46:38PM -0400, Ryan Sleevi wrote:
>
> > > It is fine for the TLS protocol to not care, but the *standard* ALPN
> > > values in the IANA registry (that might then also appear in DNS
> > > zone files, configuration
On Thu, May 20, 2021 at 01:46:38PM -0400, Ryan Sleevi wrote:
> > It is fine for the TLS protocol to not care, but the *standard* ALPN
> > values in the IANA registry (that might then also appear in DNS
> > zone files, configuration files, ...) a more restricted character
> > set would actually be
On Thu, May 20, 2021 at 1:03 PM Viktor Dukhovni
wrote:
> On Thu, May 20, 2021 at 04:45:23PM +, Andrei Popov wrote:
>
> > ALPN IDs are byte strings; the fact that some of them can be displayed
> > as ASCII character strings merely reflects the fact that those ALPN
> > IDs were chosen by humans
On Thu, May 20, 2021 at 04:45:23PM +, Andrei Popov wrote:
> ALPN IDs are byte strings; the fact that some of them can be displayed
> as ASCII character strings merely reflects the fact that those ALPN
> IDs were chosen by humans😊.
That's fine when they're just private signalling between a hom
+1 what Ryan said. Especially the point that added restrictions aren’t a viable
path to better interoperability.
ALPN IDs are byte strings; the fact that some of them can be displayed as ASCII
character strings merely reflects the fact that those ALPN IDs were chosen by
humans😊.
Cheers,
Andre
On 5/20/2021 5:28 AM, Viktor Dukhovni wrote:
On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
SVCB's syntax would need us to not only exclude non-ASCII characters but
also avoid random delimiters like commas, right? I think that's going a bit
too far. As Ryan notes, complex def
On Thu, May 20, 2021 at 11:23:15AM -0400, David Benjamin wrote:
> SVCB's syntax would need us to not only exclude non-ASCII characters but
> also avoid random delimiters like commas, right? I think that's going a bit
> too far. As Ryan notes, complex definitions for allowed strings result in
> amb
On Thu, May 20, 2021 at 03:06:06AM -0400, Ryan Sleevi wrote:
> On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
> wrote:
>
> > On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
> >
> > > I support limiting it.
> >
> > I concur. These are not strings used between users to communicate i
SVCB's syntax would need us to not only exclude non-ASCII characters but
also avoid random delimiters like commas, right? I think that's going a bit
too far. As Ryan notes, complex definitions for allowed strings result in
ambiguities around who is responsible for validating what and subtle
variati
On Thu, May 20, 2021 at 6:30 AM Salz, Rich wrote:
> Look at RFC 701, it says: the precise set of octet values that identifies
> the protocol. This could be the UTF-8 encoding of the protocol name.
>
> So I changed my mind and think it's okay to leave as-is but wouldn't mind
> if it became less ge
Look at RFC 701, it says: the precise set of octet values that identifies the
protocol. This could be the UTF-8 encoding of the protocol name.
So I changed my mind and think it's okay to leave as-is but wouldn't mind if it
became less general or more specific. For example, what if a protocol str
For better or worse, these identifiers are being used in places outside the TLS
handshake -- for example, in HTTP header fields, as Erik mentioned. That brings
the encoding / conversion concerns he mentioned. It would be simpler (and
likely safer) to only allow ASCII strings in those uses (at le
On Thu, May 20, 2021 at 1:56 AM Viktor Dukhovni
wrote:
> On Wed, May 19, 2021 at 10:29:43PM +, Salz, Rich wrote:
>
> > I support limiting it.
>
> I concur. These are not strings used between users to communicate in
> their native language. They are machine-to-machine protocol
> identifiers,
16 matches
Mail list logo
