Re: bluetooth DUN silently discarding "invalid" APNs

[Marc Herbert <Marc Herbert gmail com>]

Le 04/05/2011 21:02, Dan Williams a écrit :

> APNs are defined by GSM 03.03 section 14.9 which says:
>
> http://www.3gpp.org/ftp/Specs/html-info/0303.htm

> =====
> The syntax of the APN shall follow the Name Syntax defined in RFC 2181
> [14] and RFC 1035 [15]. The APN consists of one or more labels. Each
> label is coded as one octet length field followed by that number of
> octets coded as 8 bit ASCII characters. Following RFC 1035 [15] the
> labels should consist only of the alphabetic characters (A-Z and a-z),
> digits (0-9) and the dash (-). The case of alphabetic characters is not
> significant. The APN is not terminated by a length byte of zero.
> =====
> 

It is funny how GSM 03.03 makes the usual misinterpretation of (the
admittedly confusing) DNS RFC1035, while in the same paragraph quoting
RFC2181 which explicitly rectifies this misinterpretation (in section
11).

DNS does not put any restrictions on label characters. This
restriction came from "hostname".

> But the specification does use the word "should", which implies that
> APNs may deviate from the suggestion.

I suspect resolving the APN through DNS is not even mandatory. Some
networks could use alternative ways to select the GGSN.

> Many APNs already use '.' (which the specification does not suggest)

That is because '.' is the usual way to separate DNS labels in text
form (not on the wire). The '.' is not part of any label.

> and perhaps we should allow "_" too.

You should simply just stay clear of this whole mess and not validate
anything. This would add two new and incredibly great features:

- Restore an error message in case of a typo (as opposed to silently
  discarding user input)
- Support APNs with unusual characters.

Two new features by merely deleting some code, how great value is that?


Cheers,

Marc