[Captive-portals] Fwd: Mail regarding rfc8908

[Guillaume Marsay <[e-mail]>]

Hello,

I am writing to request a clarification regarding the behavior of the
`venue-info-url` field as defined in RFC 8908 (Captive Portal API).

The field is defined in Section 5 as an optional key with no explicit
restriction on when it should be included. However, the canonical example
in Section 6 only includes `venue-info-url` in the response where
`captive=false`, omitting it entirely from the `captive=true` response.

This has led to an ambiguity in implementations: should `venue-info-url` be
withheld when the client is in a captive state, or is the Section 6 example
purely illustrative and not normative?

This question arises from a practical issue observed in coova-chilli (
https://github.com/coova/coova-chilli/issues/613) where `venue-info-url`
is only returned for authorized sessions. This results in:

- Some Android devices (e.g., OnePlus 10 Pro) not displaying the
venue-info-url prompt even after authorization.
- iOS devices displaying user-portal-url instead of venue-info-url before
authorization.

For comparison, Section 5 explicitly states that `seconds-remaining` and
`bytes-remaining` SHOULD be omitted for captive clients — but no such
recommendation exists for `venue-info-url`. This asymmetry suggests that
including `venue-info-url` when `captive=true` may be valid and even
intended.

Could you please clarify whether:
1. `venue-info-url` MAY be included in responses where `captive=true`?
2. The example in Section 6 is purely illustrative and should not be
interpreted as a behavioral constraint?

Thank you for your time and for your work on this specification.

Best regards

-- 
Guillaume Marsay
Mail : [e-mail]