that ess in 'https'

[Dick Hardt]

What if there is no "http://" or "https://" in front of the url?

Users are used to typing in 'amazon.com' or 'google.com' or 'blame.ca/ 
dick' into their browser and the right thing happens.

They may not know (or care) wether it is http or https

-- Dick


On 26-Jun-06, at 8:08 PM, Joaquin Miller wrote:

> For a while here I thought i understood what the topic of  
> discussion was.  Now i feel i may be missing the point entirely.
>
> I thought we were trying to decide whether we should adopt the  
> convention that pairs of URLs like the following two URLs, when  
> used as identity URLs, are equivalent: identify the same persona.
>
>   http://joaquin.net
>   https://joaquin.net
>
> But much of the discussion seems to be about identifying a Yadis  
> document or a web page.  About whether we can suppose that the URLs  
> will return the same document to a GET.  Or about whether they  s h  
> o u l d  return the same document.  Or about what to make of it if  
> they happen to return different documents.  Or how best to tell if  
> the documents returned are equivalent.
>
> Now, i suppose those discussions would be relevant if we were  
> trying to meet the reasonable expectations of programmers and  
> architects.
>
> But i thought our audience was
>   the people who
>      we would like to see
>          use URLs to identify their personas.
>
> In that case, most of the discussion does not feel to me like it is  
> on target.
>
>
>
> How about let's stick for a day or so to the question: How will our  
> audience best be served: by the two URLs being equivalent, or by  
> their not being equivalent?
>
> How will our audience best be served?
> The people who we would like to see use URLs to identify their  
> personas.
>
> Cordially, Joaquin
>
> ================ there should be no need to read on.  
> ======================
>
> Here is what I thought was being discussed (spelled out in excess  
> detail, just be be perfectly clear).
>
> We use URLs as personal identifiers.
>   (They don't identify a person, exactly, but instead identify a  
> persona being used by a person (or persons).)
>     ((Such URLs might also identify some entity that is not a  
> person, but that does not matter for us in this discussion.))
>     ((We don't limit ourselves to URLs; certainly an XRI; perhaps  
> any URI; or IRI. That does not matter for us in this discussion.))
>
> An identifier is an unambiguous name, in a given naming context. [X. 
> 902 12.2]
>
> In our case, the naming context is established, in part, by the  
> internet standards, practices, and installed infrastructure.
> One part of this infrastructure is the maintenance of the domain  
> namespace by the installed DNS infrastructure.
> >  I'll call this context 'the DNS URL context', 'the usual URL  
> context' or just 'the URL context'.
>
> URLs are resource locators.  Every URL locates a resource.
>      ((Or is broken.  We could have a lot of fun arguing about the  
> concept, broken identifier, but that will not be useful for us in  
> this discussion.))
>
> Further, URLs are a kind of URI.  URIs are identifiers.  [RFC  
> 3986]  Every URL identifies a resource.
>      ((Or is broken.))
>
> In the URL context, a URL identifies a resource.
>
> Arguably, in the URL context these two URLs necessarily identify  
> different resources:
>   http://joaquin.net
>   https://joaquin.net
>     ((For us, in this discussion, that does not matter at all, one  
> way or the other.))
>
> But we also have another context, more interesting.  The context  
> provided by Yadis and by the various internet identity services,  
> such as OpenID, LID public key based identity services, MyID, Sxip,  
> and so on.
> >> I'll call this context 'the Identity URL context'.
>
> I maintain a spiffy little web page located by the URL 'http:// 
> joaquin.net '.
> I maintain a spiffy little resource identified, in the URL context,  
> by the URL 'http://joaquin.net '.
>
> At the very same time, I use that very same URL, 'http:// 
> joaquin.net', as an identity URL: an identifier of the persona i  
> present at that web site.
>
> In the URL context the URL 'http://joaquin.net' identifies my  
> spiffy little resource.
> In the Identity URL context the URL 'http://joaquin.net' identifies  
> my little persona.
>
> This amazing feat is possible because, in the Identity URL context,  
> URLs identify personas.
> Not resources.
>
> I am free to use a different identifier, 'https://joaquin.net ', to  
> identify that same little persona.
>
> Whether, in the URL context, 'https://joaquin.net' and 'http:// 
> joaquin.net' do or don't identify the same resource does not matter  
> one whit, if i happen to choose to use them to identify, in the  
> Identity URL context, the same persona.
>
> And, since we are inventing this space out of whole cloth, we are  
> perfectly free to require that they identify the same persona.  It  
> is simply a matter of our specifying a rule of the naming context.
>
> Whether, in the URL context, 'https://joaquin.net' and 'http:// 
> joaquin.net' do or don't identify the same resource does not matter  
> one whit, if we to choose to specify that they identify the same  
> persona.
>
> Which way we decide might make architects and programmers a little  
> unhappier or more pleased, might make a little more or less work  
> for us, might lead to more or fewer design and implementation  
> errors, might require more or less time, money, or thought.
>
> But none of that matters.
>
> What matters    o n l y    is what will work best for the average  
> woman in the street or at the terminal.  Or man.  Or other persona.
>