Subject: [webfinger] Default language (Was: Last Call: <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standard

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Mar 2013 11:00:58 -0400

On Mon, Mar 04, 2013 at 12:24:30PM -0800,
 The IESG <[email-masked]> wrote 
 a message of 38 lines which said:

> The IESG has received a request from the Applications Area Working Group
> WG (appsawg) to consider the following document:
> - 'WebFinger'
>   <draft-ietf-appsawg-webfinger-10.txt> as Proposed Standard

draft-ietf-appsawg-webfinger-11.txt says: 

> The "titles" object comprises zero or more name/value pairs whose
> name is a language tag or the string "default". [...] If the
> language is unknown or unspecified, then the name is "default".

Why inventing a special value when the language tag registry already
has a specific value, "und"? To quote RFC 5646:

> The 'und' (Undetermined) primary language subtag identifies
> linguistic content whose language is not determined.  This subtag
> SHOULD NOT be used unless a language tag is required and language
> information is not available or cannot be determined.

Editorial comment: the reference is wrong:

   [13]  Phillips, A., Davis, M., "Tags for Identifying Languages", RFC
         5646, January 2001.

[It is 2009]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Mar 2013 11:18:47 -0400

Another issue with language tags in draft-ietf-appsawg-webfinger-11.txt:

> "titles" :
>           {
>               "en-us" : "The Magical World of Bob",
>               "fr" : "Le Monde Magique de Bob"
>           }

I understand that the purpose of the example is to show that you are
not limited to the primary langauge subtag, you can add other subtags
(here, the region "us"). But the example is not well chosen. RFC 5646 says:

>      Use as precise a tag as possible, but no more specific than is
>      justified.  Avoid using subtags that are not important for
>      distinguishing content in an application.
>
>       * For example, 'de' might suffice for tagging an email written
>          in German, while "de-CH-1996" is probably unnecessarily
>          precise for such a task.

Which seems to apply exactly here (there is nothing US-specific in the
sentence). May be, instead:

"titles" :
           {
               "en-us" : "The Magical Theater of Bob",
               "en-gb" : "The Magical Theatre of Bob",
               "fr" : "Le Théâtre Magique de Bob"
           }

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Mar 2013 16:02:38 +0000

I'll raise a related issue - the case of characters used in language tag values.  Given that "en-us" and "en-US" are different JSON values, it's important for people to spell language tag values in a consistent way.

http://tools.ietf.org/html/rfc5646#section-2.1.1 makes specific recommendations. We should probably call them out - in particular, that tag elements SHOULD be spelled as in the IANA registry at http://www.iana.org/assignments/language-subtag-registry.

In the case of US English used in the example, the recommended spelling appears to be "en-US".

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephane Bortzmeyer
Sent: Friday, March 15, 2013 8:19 AM
To: [email-masked]
Cc: [email-masked]
Subject: [webfinger] Language tag too specific (Was: Last Call: <draft-ietf-appsawg-webfinger-10.txt> (WebFinger) to Proposed Standard

>          in German, while "de-CH-1996" is probably unnecessarily

Which seems to apply exactly here (there is nothing US-specific in the sentence). May be, instead:

"titles" :
           {
               "en-us" : "The Magical Theater of Bob",
               "en-gb" : "The Magical Theatre of Bob",
               "fr" : "Le Théâtre Magique de Bob"
           }
_______________________________________________
webfinger mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/webfinger

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 18 Mar 2013 11:28:09 +0900

> I'll raise a related issue - the case of characters used in language tag values.  Given that "en-us" and "en-US" are different JSON values, it's important for people to spell language tag values in…

Hello Mike,

Language tags are case-insensitive, so whether it says "en-US" or 
"en-us" (or any other combination of caps and lower case), the final 
result (that those people who prefer English as used in the US get to 
see the title version that's labeled "en-US" or "en-us") should be the same.

Of course, it might be that there are two separate titles with match 
case-insensitively. Here's an example:

"titles" :
             {
                 "en-us" : "The Magical Theater of Bob",
                 "en-gb" : "The magical theatre of Bob",
                 "en-GB" : "The Magical Theatre of Bob",
                 "fr" : "Le Théâtre Magique de Bob"
             }

While the author might have intended for the user to select the lower 
case or the titlecase version of the title, that just won't work. So I 
guess we should call out this case and prohibit it for producers.

But I don't see the reason to specify that everybody has to use "en-GB"; 
using "en-gb" only should just do as well.

Regards,   Martin.

> Subject: [webfinger] Language tag too specific (Was: Last Call:<draft-ietf-appsawg-webfinger-10.txt>  (WebFinger) to Proposed Standard
>

---

From: Mark Davis ☕ <[email-masked]>
Date: Fri, 15 Mar 2013 17:06:25 +0100

I don't think that's an improvement. If I speak en-AU, which do I get?
Better would be just:

"titles" :
           {
               "en" : "The Magical Theater of Bob",
               "fr" : "Le Théâtre Magique de Bob"
           }

Mark <https://plus.google.com/114199149796022210033>
*
*
*— Il meglio è l’inimico del bene —*
**

On Fri, Mar 15, 2013 at 4:18 PM, Stephane Bortzmeyer <[email-masked]>wrote:

> Ietf-languages mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
>

---

From: Mark Davis ☕ <[email-masked]>
Date: Fri, 15 Mar 2013 20:38:41 +0100

Your formulation points out that the results depend heavily on the matching
algorithm.
Without context I don't know what that is.

We, for example, identify en with the most populous country, eg the US.

{phone}
On Mar 15, 2013 6:26 PM, "John Cowan" <[email-masked]> wrote:

> Mark Davis ☕ scripsit:
> Less than half of all anglophones will like that less than half as well
> as it might deserve, abstractly considered.  How about this?
>
> "titles" :
>            {
>                 "en" : "The magical theatre of Bob",
>                 "fr" : "Le théâtre magique de Bob"
>            }
>
> In that way, all non-Yank anglophones get the right answers for them.
> Of course, you can't always count on such a piece of luck.
>
> --
> John Cowan          http://www.ccil.org/~cowan         [email-masked]
> The native charset of SMS messages supports English, French, mainland
> Scandinavian languages, German, Italian, Spanish with no accents, and
> GREEK SHOUTING.  Everything else has to be Unicode, which means you get
> only 70 16-bit characters in a text instead of 160 7-bit characters.
>

---

From: Mark Davis ☕ <[email-masked]>
Date: Mon, 18 Mar 2013 15:51:42 +0100

If you are referring to RFC 4647, ​I'm reasonably familiar with it, being
one of the editors. I t​ is well recognized that it often doesn't produce
the best results. It is more a ​minimum bar than the be-all-and-end-all.

As for "ad hoc proprietary algorithm". Not so much; we use the algorithms
​from
 Unicode LDML.

On Mon, Mar 18, 2013 at 3:39 PM, John Cowan <[email-masked]> wrote:

> Well, that's because you use an ad-hoc proprietary algorithm rather than
> any of the three standard ones.
>
> --
> Kill Gorgun!  Kill orc-folk!            John Cowan
> No other words please Wild Men.         [email-masked]
> Drive away bad air and darkness         http://www.ccil.org/~cowan
> with bright iron!   --Ghan-buri-Ghan    http://www.ccil.org/~cowan
>

---

From: John Cowan <[email-masked]>
Date: Fri, 15 Mar 2013 13:26:30 -0400

"titles" : 
           {

---

From: John Cowan <[email-masked]>
Date: Mon, 18 Mar 2013 10:39:45 -0400

---

From: Mark Davis ☕ <[email-masked]>
Date: Tue, 19 Mar 2013 07:10:11 +0100

Normally you would not mark different names according to their source
language. Markup as follows would be pedantic, and more likely screw up any
software reading it than have a positive effect.

<span lang="en">I gave a book to my friend </span><span
lang="fr">Pierre</span> <span lang="de">Schmidt</span>.

Note also that often titles of movies, plays, etc are either untranslated,
partially translated, or untranslated, such as where I live:

http://www.google.ch/movies?hl=de&near=Zurich&dq=movies&sort=1&q=movies&sa=X&ei=6QBIUfD3Hs29Pcm1gfgN&ved=0CCoQxQMoAA

On Mon, Mar 18, 2013 at 7:16 PM, Richard BUDELBERGER <
[email-masked]> wrote:

> > Message du 15/03/13 18:27
> > De : "John Cowan"
> > A : "Mark Davis"
> > Copie à : [email-masked], [email-masked]
> > Objet : Re: Language tag too specific
> >
> >> Mark Davis scripsit:
> >> "titles" :
> >> {
> «Bob» being an unFrench name:
>
> "titles" :
> {
> "fr" : "Le théâtre magique de" "en-us" : "Bob"
> }
>

---

From: Mark Davis ☕ <[email-masked]>
Date: Tue, 19 Mar 2013 17:38:37 +0100

Here is what I sent. Looks like the mailer munged it.

On Tue, Mar 19, 2013 at 5:19 PM, Richard BUDELBERGER <
[email-masked]> wrote:

> > Message du 19/03/13 07:10
> > De : "Mark Davis ☕"
> > A : "Richard BUDELBERGER"
> > Copie à : "John Cowan" , [email-masked],
> [email-masked]
> language.
> >Markup as follows would be pedantic, and more likely screw up any software
> >reading it than have a positive effect.
> >
> >I gave a book to my friend Pierre Schmidt.
>
> I gave a book to my friend Pierre Schmidt.
> !!!…
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Mar 2013 22:38:26 -0400

Hannes,
 
> I was hoping that some of the remarks that I provided last year (e.g.,
> http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html) would
> help to clarify the content of the document. That didn't quite happen...

Yeah, I wasn't copied.
 
> In earlier versions of the document I had the impression that the acct:
> URI scheme always had to be used as input to the lookup process but as
> Section 4.5 explains this is not necessary. The resource parameter may
> contain other URIs as well. Section 4.5 does not give a lot of
> description of when certain URIs are utilized. 

Correct, any URI might be used.  That does not mean that the server will respond for every URI, but some wanted "acct" and "email" and "tel" URIs, for example.  Also, using an HTTP URI could be used to return additional information about a URI.
 
> For example, in Section 3.1 the example talks about a user receiving an
> email from [email-masked] and this email address is then used by
> WebFinger but the request example shows an acct: URI scheme (rather than
> a mailto URI). It seems that there is the unstated assumption (at least
> in that example) that the mailto URI is the same as the acct: URI, which
> of course isn't necessarily the case. I believe it would be good to
> state these assumptions to avoid confusing the reader. 

Fair point.  How about immediately following the example, we add:
'Note the assumption made in above example that there is an "acct" URI for the given "mailto" URI.  This is not always the case.'

> Think about it: If you receive a SIP URI (which also has an email alike
> structure with a username @ domain part) that does not mean either that
> you can use this as an email address either. In some rare cases you
> might. 

That's definitely true.  However, this is one reason for encouraging the use of the "acct" URI scheme, though.  In general (though not always), there is account associated with the user.  The SIP URI, mailto URI, etc., each have a user part.  I believe it is a reasonable assumption that there *may be* an 'acct' URI for the user.  If not, WF will return nothing.

We intended WF to be useful to humans, too, which means that if a user sees [email-masked], the user will assume that might be a means of reaching "paulej" at "packetizer.com" using any number of tools (email, XMPP, H.323, etc.).  They would be correct for most.  Thus, there is encouragement for WF servers to use the acct URI.
 
> If you believe that everyone would get the difference anyway (because
> the URI scheme determines the semantic of the identifier) then have a
> look at the Google WebFinger page (see
> http://code.google.com/p/webfinger/). At least these guys don't
> understand the difference either. 

There was even a proposal that we use no URI scheme at all and merely have the user@domain identifier.  However, there is value in using a proper URI with WF, since querying "h323:[email-masked]" might return the address of my Gatekeeper, for example, versus the information that would be returned for my account. 

> In general, I am wondering whether there are additional assumptions
> implied about the URI scheme associated with the identifier in the
> lookup mechanism. For example, the text in Section 3.3 talks about email
> client configuration and it seems that the requestor is interested in
> receiving information about the email configuration based on the
> resource=mailto... URI scheme usage. If I use a different URI scheme
> (like a aaa: URI scheme) would my response look different?

Yeah, it might look different.  What a WF server wishes to return for a given URI is really up to the administrator.  It might be that the same information is returned for any given URI scheme having the same user@domain part, but the server could return different responses.
 
> Then, there is a question about the lack of privacy considerations in
> the document. 

We do have quite a bit of text in the security considerations section.  This will be called out more clearly with sub-sections, but there are at least three full paragraphs on privacy, even going to the point of providing the example that sharing location information might put a person in danger from someone who wishes to inflict harm on them.  Personally, I thought that went a bit overboard, but that text was requested, so it's there.
 
> The usage of the WebFinger mechanism requires the requestor to have
> access to the full username@domain identifier. While this may be OK in
> some cases when the response relates very much to the specific user
> account it may be a problem in other cases. For example, in the OAuth
> case there is the idea that the user identifier may be hidden from the
> relying party but you have just required that identifier to be provided
> to the relying party to start the entire OAuth exchange (in the
> discovery).

WF is not for use with every protocol, so I cannot address OAuth generically.  However, WF *is* used as a part of OpenID Connect.  So, yes, the user provides his/her identifier to the RP.  However, that decision is a matter outside the scope of WF.

> The example in Section 3.1 returns information that relates to the
> specific username and therefore it makes sense to provide the username
> part of the identifier to the service that constructs the query. For the
> OpenID Connect discovery procedure described in Section 3.2 I wonder
> whether this is always desirable.

This was requested as an example to align with the OpenID Connect specs.

> Could you expand the description a bit to explain why the relying party
> in this case has to obtain the username part as well? The returned
> information does not seem to be specific to a certain user. It is the
> server configuration. It would be nice if the configuration of an
> identity provider software (e.g., OpenID Connect) is not different for
> every user. 

I'm not sure what to add, but I would welcome input.  My understanding is that this is how OpenID Connect works.  If I were to visit a web site and log in, what do I provide the site?  It would not necessarily have to be my email address.  It could be [email-masked]  Whatever the case, something has to be provided.  A simple user@domain identifier is something most users understand.  The URIs used with OpenID were not so friendly for the average user.
 
> I believe it is just fair to ask for a warning to be added to the
> security consideration section indicating that WebFinger may have an
> impact on your privacy expectation since it shares information with the
> relying party that other mechanisms do not provide. So, if you think
> that this just works like other discovery mechanisms the IETF had worked
> on in the past then you might be surprised. 

I'm OK with introducing more text to the security considerations section, but it should not be heavily focused on OpenID or OpenID Connect.  Many readers of this spec would not even know what a "relying party" is, ether.  We should keep it generic.
 
> I would even volunteer to provide text but I fear that you are not going
> to like it. 

:-)  Well, I didn't like some of the other text that was added, but I accepted it since people demanded it.  If there is another broad point that needs to be made, then I'm willing to add the text.  I just added a section on "abuse potential", as you might have seen.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Mar 2013 22:55:18 -0400

Stephanie,

> > The "titles" object comprises zero or more name/value pairs whose name
> > is a language tag or the string "default". [...] If the language is
> > unknown or unspecified, then the name is "default".
> 
> Why inventing a special value when the language tag registry already has
> a specific value, "und"? To quote RFC 5646:
>
> > The 'und' (Undetermined) primary language subtag identifies linguistic
> > content whose language is not determined.  This subtag SHOULD NOT be
> > used unless a language tag is required and language information is not
> > available or cannot be determined.

This is historical.  The JRD syntax was first defined in RFC 6415 and that
document said to use "default" when the corresponding XML document did not
specify the xml:lang attribute.

We could change it, but it would break any existing implementations of RFC
6415.
 
>    [13]  Phillips, A., Davis, M., "Tags for Identifying Languages", RFC

That's an easy one.

Thanks!
Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 20 Mar 2013 23:01:13 -0400

Stepane,

> I understand that the purpose of the example is to show that you are not
> limited to the primary langauge subtag, you can add other subtags (here,
> the region "us"). But the example is not well chosen. RFC 5646 says:
> 

You example illustrated why there is value in specifying the region in this example.  However, I really do not care what we use as language tags.  I selected these examples just to show that one might use a language value only or a language and region value.

What would you prefer we have in the example?

Paul