RE: Review of draft-ietf-geopriv-http-location-delivery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



That's not just a good compromise, I think it's necessary.

However, I should point out that this document only describes the former (implicit IP identification) and therefore I'm happy to defer dealing with the other in extension documents.

--Martin

From: Bernard Aboba [mailto:bernard_aboba@xxxxxxxxxxx] :

> New (Barnes):
> 
> A Device that conforms to this specification MAY omit support for HTTP 
> authentication [RFC2617] or cookies [RFC2965]. Because the Device and 
> the LIS may not necessarily have a prior relationship, it is RECOMMENDED 
> that that the LIS not require a Device to authenticate, either using the 
> above HTTP authentication methods or TLS client authentication.

The previous text related to LIS behavior (e.g. not refusing authorization
based on lack of authentication).  This suggested text relates to the 
client (e.g. that it may omit support for HTTP authentication, TLS
client auth or cookies). 

In the previous text, the LIS could challenge the client, but was 
restricted in its options if the client failed authentication.  In this
text, the LIS is recommended not to even try to authenticate
the client. 

A compromise approach would be for the LIS to make the choice 
on whether to challenge the device based on the nature of the request. 
Devices only supporting requests that cannot be challenged (e.g. 
requests utilizing implicit IP address identification)
could omit support for HTTP authentication.  However, if
a device were to make a request of another type (e.g. utilizing
HELD extensions), the LIS could challenge it and therefore the device 
would need to support HTTP authentication. 


------------------------------------------------------------------------------------------------
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]
_______________________________________________Ietf mailing listIetf@xxxxxxxxxxxxx://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]