Sorry, Martin, I was trying to limit my comments. I felt bad enough that I
started this fire. I didn't want to pour more gas on it!
But that said, I wasn't sure what Sebastian meant by "support". It seemed
like that he meant that the underlying server package had to have the
*ability* to support SSL/TLS, but it didn't have to be enabled.
But if that's the requirement, then it seems to me that it's impossible to
determine whether an ALTO server satisfies it. To an outside observer,
what's the difference between "this computer has TLS software, but the
admin didn't configure a TLS listener on port 443" vs "there's no TLS
software there at all"?
It's like deciding whether a falling tree makes a noise if there's no way
to observe it. ;-)
I would understand a "MUST support SSL/TLS" requirement if it's treated as
a requirement on software packages marketed as ALTO servers. That is, if I
write a system and claim that it conforms to the ALTO RFC, then my
software package must support TLS. However, when deploying my ALTO server,
the purchaser may choose to turn the TLS option off.
That, at least, is decidable. But I thought RFCs were about the external
behavior of deployed systems, not about requirements on software
implementations of those specifications.
- Wendy Roome
On 03/07/2013 06:45, "Martin Stiemerling" <[email protected]>
wrote:
>>
>>For what it is worth, the exact phrasing in -14 confuses me: "An ALTO
>>Server MUST support SSL/TLS [RFC5246] to implement server and/or
>>client authentication, encryption, and/or integrity protection." I
>>could read this in a way that the ALTO server MUST announce all
>>services on HTTPS URIs, and this is certainly not what we want. (And,
>>having "and/or" in a MUST statement might not be perfect.)
>>
>>If the consensus is the MUST, I'd at least prefer Sebastian's
>>wording: "Any ALTO implementation MUST support SSL/TLS [RFC5246]".
>
>Sebastian's proposal is better, indeed.
>
>That's by the way the same proposal I have asked Wendy at some point,
>but didn't get response ;)
>
> Martin
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
