This is related to my previous "Allowable mailto contacts" thread earlier
this month. However, this is about a different type of contact, so I
decided to start a new thread.
Although ACME servers don't have to include support for "tel" (RFC 3966)
contacts, "tel" contacts appear in multiple examples in the ACME
specification. Thus, some may try to include "tel" contact support in their
ACME server implementations.
Although the example "tel" contacts in the ACME specification seem to
indicate a simple, narrow subset (the "global-number" with zero "par"
instances), the "tel" specification has many more possible productions. For
example, both "global-number" and "local-number" may have "par" instances
(like ";name1=value1;name2=value2") after the phone numbers.
Assuming I understand the "local-number" specification correctly, a
"local-number" could potentially contain a pound sign ("#") for reasons
related to DTMF. If I understand the current and past URI specifications
correctly, this could be problematic. Specifically, a URI parser may put
the parts of the "local-number" after a "#" in the fragment.
If someone wanted to implement "tel" contact support for an ACME server,
what subset of "tel" would be required? Would both "global-number" and
"local-number" instances be allowed? What restrictions would apply to
"global-number" and "local-number" instances? Which types of "par"
instances would be allowed? Extension? ISDN-subaddress? Others?
On a more general note, I think that as ACME becomes more widely used, the
subject of what subsets of what contact URI schemes would be allowed under
ACME (as opposed to what schemes are supported by a specific ACME server,
which was a separate issue already discussed in March on the mailing list
under "Allowing clients to understand the account creation functionality
supported by a server") may come up more often. Would it be a good idea to
request the creation of an "ACME Contact Schemes Registry" like in the
ASCII art figures below?
+--------+-----------+-----------+--------------------------
-------------------+
| Scheme | Status | Reference | ACME Restrictions
|
+--------+-----------+-----------+--------------------------
-------------------+
| mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to"
portion |
| | | | No "hfields" are allowed
|
| | | | [Source: "Allowable mailto contacts"
thread]|
+--------+-----------+-----------+--------------------------
-------------------+
| tel | Optional | RFC 3966 | [insert restrictions picked in this
thread] |
+--------+-----------+-----------+--------------------------
-------------------+
Figure 1: A possible "ACME Contact Schemes Registry" table. In this
version, the ACME restrictions on the original contact scheme
specifications are stated in the table, and the original contact scheme
specification is listed as the "Reference". These relationships are
depicted graphically in Figure 2 (below).
+-----------------------+ +--------------------+
| RFC 6068 (mailto RFC) | | RFC 3966 (tel RFC) |
+-----------------------+ +--------------------+
Figure 2: RFC relationships for Figure 1
+--------+-----------+---------------------------+
| Scheme | Status | Reference |
+--------+-----------+---------------------------+
| mailto | Mandatory | RFC XXXX |
| | | (ACME RFC) |
| | | |
+--------+-----------+---------------------------+
| tel | Optional | RFC YYYY |
| | | (Some RFC after RFC XXXX) |
+--------+-----------+---------------------------+
Figure 3: Another possible "ACME Contact Schemes Registry" table. In this
version, the "Reference" RFCs discuss the ACME-specific restrictions for
the contact schemes, and refer to the original specifications for the
contact schemes. These relationships are depicted graphically in Figure 4
(below).
+-----------------------------+
| ACME restrictions on mailto |
+----------+------------------+
^
|
| Contains
|
+----------+----------+ +--------------+
| RFC XXXX (ACME RFC) | References | RFC 6068 |
+ +----------------> + (mailto RFC) |
| | | |
+----------+----------+ +--------------+
^
|
| References
|
+----------+-------------------+ +-----------+
| RFC YYYY | References | RFC 3966 |
+ (An RFC after RFC XXXX) +----------------> + (tel RFC) |
| | | |
+----------+-------------------+ +-----------+
^
|
| Contained in
|
+----------+------------------+
| ACME Restrictions on tel |
+-----------------------------+
Figure 4: RFC relationships for Figure 3 version of "ACME Contact Schemes
Registry"
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
