Re: [Geopriv] The 's' in HELD

[Richard Barnes <[e-mail]>]

Sure, that's fine with me.  As long as both options are supported.
--RB


Mary Barnes wrote:
> Richard,
> 
> I see your point, however, wouldn't we then want to define both "held:"
> and "helds:"? That's been the approach of other protocols that I'm aware
> of (e.g., SIP, MSRP, etc.).  
> 
> Mary. 
> 
> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]] 
> Sent: Wednesday, April 30, 2008 2:01 PM
> To: Thomson, Martin
> Cc: GEOPRIV; Barnes, Mary (RICH2:AR00)
> Subject: Re: [Geopriv] The 's' in HELD
> 
> I've gotten a note off-list that indicates a need to clarify this
> comment:
> 
> My impression is that the document as it is does not require TLS be
> *used* on every transaction (which is the implication that led to
> HELDS), just that it be *available* for every transaction.  I think the
> confusion is founded in the below text from Section 9:
> 
>     The implementation of HTTP as a transport mechanism MUST implement
>     TLS as described in [RFC2818].  TLS provides message integrity and
>     privacy between Device and LIS.  The LIS MUST use the server
>     authentication method described in [RFC2818]; the Device MUST fail a
>     request if server authentication fails, except in the event of an
>     emergency.
> 
> You can read that paragraph in either way (implement/use): The first
> sentence says that TLS is a "MUST implement" (not a "MUST use"), but the
> third sentence implies that the server MUST use TLS to authenticate.
> 
> There's no mandate for TLS to be used in the security considerations,
> only supported by implementations.  The mandates in the security
> considerations are in the form "IF you want this security property, THEN
> use TLS", the usual MO in IETF docs.
> 
> Am I understanding the document correctly, or is there some other
> section that specifies that TLS MUST be used on every transaction.
> 
> If TLS is not required, then here are some proposed (minor) changes:
> 1. Add "When TLS is used, ..." to the third sentence in the above
> paragraph, in order to clarify that the requirement is not absolute.
> 2. Change the "HELDS" URI scheme back to "HELD"
> 
> --Richard
> 
> 
> 
> 
> 
> 
> 
> Richard Barnes wrote:
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>> _______________________________________________
>> Geopriv mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>>
> 
> 
> 
_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv