Re: [Geopriv] The 's' in HELD

["Thomson, Martin" <[e-mail]>]

Thanks all for the explanation, but that was all I was looking for.

Speaking about the proposed; I like the concept.  Flexibility and such a
small change...

I do wonder whether there is any potential for interoperability problems
if the same URI is used for both TLS and unadorned TCP sessions.  If
there's no real problem with mixing the two, then I'm all for the
change; otherwise, let's leave be and leave implementations to agree
(amoungst themselves) to use TLS_NULL_WITH_NULL_NULL if they want to.

Cheers,
Martin

p.s. The 's' smells bad, but I can live with worse (c.f.
emergencyRouting/emergencyDispatch).

> -----Original Message-----
> From: Richard Barnes [mailto:[e-mail]]
> Sent: Thursday, 1 May 2008 5:27 AM
> To: Mary Barnes
> Cc: Thomson, Martin; GEOPRIV; Eric Rescorla
> Subject: Re: [Geopriv] The 's' in HELD
> 
> 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
> >>
> >>
> >
> >
> >

------------------------------------------------------------------------------------------------
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