Re: [Geopriv] The 's' in HELD

["Mary Barnes" <[e-mail]>]

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