Subject: Re: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions

From: Logan Widick <[email-masked]>
Date: Fri, 17 Nov 2017 10:12:45 -0600

Or, would it be best to remove the non-mailto contacts from the examples,
and add a note indicating that "mailto" is the only contact URI scheme
currently supported by the ACME standards?

Sincerely,

Logan Widick

On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick <[email-masked]>
wrote:

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

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 17 Nov 2017 12:17:25 -0500

I would be supportive of removing non-mailto contact examples.

I don't think it's accurate to say that "mailto" is the only contact scheme
currently supported by the ACME standard. That isn't the case for the spec
as-written today - it is the only mandatory contact scheme. I believe its
been left intentionally open ended what other schemes may be supported by a
server.

In my mind ACME servers wishing to support `tel` should come up with their
own understanding of what parts of the relevant RFCs they support and use
the `unsupportedContact` and `invalidContact` errors as appropriate based
on the `tel://` contacts received. I don't think there is value trying to
create a subprofile of `tel` for ACME use that is defined in the ACME draft.

- cpu

On Fri, Nov 17, 2017 at 11:12 AM, Logan Widick <[email-masked]>
wrote:

>> 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?
>>
>>
>>
>>
>> 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 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Logan Widick <[email-masked]>
Date: Fri, 17 Nov 2017 14:53:47 -0600

Here is a PR to remove the "tel" contacts from the examples:
https://github.com/ietf-wg-acme/acme/pull/353

In the PR, I am assuming that the ACME servers can support additional
contact schemes (schemes not defined in ACME specs) but must document
(somehow) what subsets of what additional schemes are supported. However, I
haven't added any text indicating this assumption. I also haven't added any
text indicating how the subsets of the additional contact schemes can be
documented.

Is this assumption correct? If so, should the assumption be documented any
further in the spec? If so, what would be the best way to document this
assumption further?

Logan

On Fri, Nov 17, 2017 at 11:17 AM, Daniel McCarney <[email-masked]>
wrote:

> I don't think it's accurate to say that "mailto" is the only contact
> scheme currently supported by the ACME standard. That isn't the case for
> the spec as-written today - it is the only mandatory contact scheme. I
> believe its been left intentionally open ended what other schemes may be
> supported by a server.
>
>>> 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.
>>>
>>> Figure 4: RFC relationships for Figure 3 version of "ACME Contact
>>> Schemes Registry"
>>>
>>
>>