On 12/2/14, 10:24 PM, Patrik Fältström wrote:
On 3 dec 2014, at 04:04, Peter Saint-Andre - &yet <[email protected]> wrote:
Hi Patrik,
On 11/26/14, 11:28 PM, Patrik Fältström wrote:
I intend reading the mapping document today, sorry for the delay but
$dayjob has been kind of ultra-busy...
Note that most issues I have have to do with clarifications, and that
it is not clear what the intent is.
Yes, I will reply to your big message next.
Maybe a few where I urge caution. And they are definitely mapping
related.
Clarifying question: are you talking about mapping in general (which might
include width mapping, mapping non-ASCII space characters to ASCII space, case
mapping, or in some nomenclatures even Unicode normalization), or only the kind
of locale and context dependent mapping that is discussed in
draft-ietf-precis-mappings?
I talk about any kind of transformation of a string.
Let me phrase it this way:
One of the problems with IDNA2003 was that it included mapping. It
was unclear to people whether the client or server did the mapping.
In reality the only place where mapping could exist for a stable
protocol/implementation was between application/User Interface and
where the protocol was really "doing things". So mapping was ripped
out of IDNA when IDNA2008 was created.
In the PRECIS WG we've had quite a bit of discussion about the dividing line
between application and protocol, or more precisely between between the user
interface (which can more easily handle issues of culture, context, intent,
locale, device limitations, etc.) and the actual use of conformant strings in
protocol slots.
Not surprising (and yes, I have seen some of this without claiming I did follow
it).
(Unfortunately, much of our most productive discussion has happened in sessions
at IETF meetings, not on the list, so it's hard to find pointers.)
Precis has decided mapping is still part of the protocol definition,
Well, draft-ietf-precis-mappings is only an informative reference from
draft-ietf-precis-framework and with good reason: we reached the conclusion a
few IETF meetings ago that we simply couldn't provide normative recommendations
here.
Ok. Which I think is fair and good.
and I must understand where more exactly you expect mapping to
happen, what happens if that mapping is not done, how to expect to do
matching (comparison) between strings in the over all environment
where it is possibly unknown whether mapping has been done or not,
and specifically how it might impact the architecture in the cases
where the mapping is destructive to the string itself (non-reversible
mapping).
I do not think it is clear in the framework WHERE mapping is to
happen.
When you say "WHERE", do you mean (1) when in the process of handling an
internationalized string or (2) by which entity in a protocol interaction?
Mainly (1) but that implies (2), right.
I think we have been clear about (1), or at least we've tried to be clear - see
for example Section 6 of draft-ietf-precis-framework.
That only specifies in what order the operations take place. It does not say
when it happens.
Example:
A send a string X to B. B store the string, which can be a username or password.
Later C send a string Y to B. B is to look up that string among stored strings,
to see whether in this case X == Y or not.
Where in the flow A -> B(store) - B(lookup) <- C are the steps in section 6
taking place?
You have some string flowing between A and B(store), some string stored, some
string flowing between C and B(lookup) and then some string is looked up. Which
ones of these strings passed around have to live up to what requirements?
Yes, that is very important, and we have tried to make that clear in
application specs that are using PRECIS. For instance, 6122bis says:
Enforcement entails applying all of the rules specified in this
document. Enforcement of the XMPP address format rules is the
responsibility of XMPP servers. Although XMPP clients SHOULD prepare
complete JIDs and parts of JIDs in accordance with this document
before including them in protocol slots within XML streams, XMPP
servers MUST enforce the rules wherever possible and reject stanzas
and other XML elements that violate the rules (for stanzas, by
returning a <jid-malformed/> error to the sender as described in
Section 8.3.3.8 of [RFC6120]).
Entities that enforce the rules specified in this document are
encouraged to be liberal in what they accept by following this
procedure:
1. Where possible, map characters (e.g, through width mapping,
additional mapping, special mapping, case mapping, or
normalization) and accept the mapped string.
2. If mapping is not possible (e.g., because a character is
disallowed in the FreeformClass), reject the string and return a
<jid-malformed/> error.
Enforcement applies to complete JIDs and to parts of JIDs. To
facilitate implementation, this document defines the concepts of "JID
slot", "localpart slot", and "resourcepart slot" (similar to the
concept of a "domain name slot" for IDNA2008 defined in
Section 2.3.2.6 of [RFC5890]):
JID Slot: An XML element or attribute explicitly designated in XMPP
or in XMPP extensions for carrying a complete JID.
Localpart Slot: An XML element or attribute explicitly designated in
XMPP or in XMPP extensions for carrying the localpart of a JID.
Resourcepart Slot: An XML element or attribute explicitly designated
in XMPP or in XMPP extensions for carrying the resourcepart of a
JID.
A server is responsible for enforcing the address format rules when
receiving protocol elements from clients where the server is expected
to handle such elements directly or to use them for purposes of
routing a stanza to another domain or delivering a stanza to a local
entity; two examples from [RFC6120] are the 'to' attribute on XML
stanzas (which is a JID slot used by XMPP servers for routing of
outbound stanzas) and the <resource/> child of the <bind/> element
(which is a resourcepart slot used by XMPP servers for binding of a
resource to an account for routing of stanzas between the server and
a particular client). An example from [RFC6121] is the 'jid'
attribute of the roster <item/> element.
A server is not responsible for enforcing the rules when the protocol
elements are intended for communication among other entities,
typically within the payload of a stanza that the server is merely
routing to another domain or delivering to a local entity. Two
examples are the 'initiator' attribute in the Jingle extension
[XEP-0166] (which is a JID slot used for client-to-client
coordination of multimedia sessions) and the 'nick' attribute in the
Multi-User Chat extension [XEP-0045] (which is a resourcepart slot
used for administrative purposes in the context of XMPP chatrooms).
In such cases, clients SHOULD enforce the rules themselves and not
depend on the server to do so, and client implementers need to
understand that not enforcing the rules can lead to a degraded user
experience or to security vulnerabilities. However, when an add-on
service (e.g., a multi-user chat service) handles a stanza directly,
it ought to enforce the rules as well, as defined in the relevant
specification for that type of service.
Is that kind of text specific enough for you?
I think we need to define this at the level of the application protocol
because that's where the rubber meets the road and where we can
legitimately talk about the various entities involved (at the level of
the PRECIS framework we don't know what the entities are and what their
responsibilities are).
As another example, see this recent discussion in the PCP WG:
http://www.ietf.org/mail-archive/web/pcp/current/msg03819.html
Peter
--
Peter Saint-Andre
https://andyet.com/
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
