Re: [Geopriv] The 's' in HELD

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Wed Apr 30 2008 - 13:57:12 EDT

Is TLS really used for every HELD transaction, as opposed to being
available for every transaction? This seems to be a deviation from the
normal pattern for Internet protocols to have a base protocol without
TLS and an (mandatory) option to use TLS as desired. More importantly,
it seems like TLS might be undesirable in some circumstances, e.g.,
emergency calling.

Is there a reason for this extra-strong requirement?

--RB

Thomson, Martin wrote:
> I missed this in the changes for -06. Please forgive my ignorance, but
> I wasn't there at -71 and it appears that only the conclusion was
> captured, not the rationale. The minutes focus on whether there should
> be a URI scheme or not, but make what seems (to me) to be a logical
> leap:
>
> Question: Does this HELD: scheme require TLS? Ans: Yes. Then
> it needs
> to be a HELDS: scheme.
>
> I don't believe that the letter 's' addresses "concerns over referential
> integrity" as stated by the held-06 change-log. So can anyone justify
> the above statement? Is there some IETF guideline I don't know of that
> states that URI schemes for protocols that use TLS have an extra 's'?
>
> Cheers,
> Martin
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original. Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Wed, 30 Apr 2008 13:57:12 -0400

This archive was generated by hypermail 2.1.8 : Wed Apr 30 2008 - 13:57:15 EDT