Stop me if I've misunderstood...

[Paul Hoffman]

At 7:02 PM +0000 7/10/09, Shawn Steele wrote:
>Which two parties are interoperating?

That's the big question. Once we get past that, we can define what interoperating means.

>In order to prevent misunderstandings, if the working group leadership feels there's consensus that requirements from vendors are desirable, I'd like that request to be clearly made by the WG leadership of ALL interested vendors, not just us.  I'm also concerned that gathering more formal requirements will delay the process :(

I'm far from the leadership here. I'm an individual trying to get the WG to come to clarity. Someone who works for a vendor of one type of system that uses IDNs started talking about interoperability, so I asked for clarification. I do not want him, nor the vendor he works for, nor even the type of system that they produce, to be the only voice here.

So, to be clear: it will not be helpful for Vendor A of Product B to say "this is our official view of what interoperability is". What would be helpful is for people who are saying that the current versions of the documents are unclear about interoperability, or are clear but insufficient, to say what they mean by interoperability.

I am betting that it will be harder than you expect to get agreement across application types, vendors, and users.

> > If you want to make a run at a concise definition, that would be still be most
>> appreciated, at least by me.
>
>Yes, I approached it more of a list of the characteristics of an interoperable environment, not by a concise definition.  Mark also made me realize I'm often speaking from the browser, not registry, perspective.  My 2nd attempt (deleted) was also probably not what you're looking for, so I'll have to think a bit.

As do we all.

> > Yes. Some argue that if the circumstance is "mandatory, fixed, and in the
>> protocol", then it is undesirable.
>
>I believe we need to recognize that there are two environments that need supported.  Mark said used "registrar" for one, but I think that perhaps "strict" and "permissive" might be more useful.  I can imagine that some applications (not web browser type) might want a "strict" approach, whereas others need mapping.  I agree with Mark that browsers MUST map, otherwise you have chaos, however I'm not sure I want to say "X, Y & Z" must map and "A, B & C" must not map.  I think saying that some applications SHOULD map is sufficient.

Stop right there. Read the definition of "SHOULD" in RFC 2119. Come up with a proposed sentence (not idea) that expresses what you want that meets the RFC 2119 rules.

We can't rely on RFC 2119 and then blow off its semantics.

>For example: If I make a contact in an address book (or friends list or whatever) with a "web page" field, then that field MUST be mapped to be useful. 

"MUST ... to be useful" is not RFC 2119 language.

>But I can't just say "address books" MUST map because I probably expect the field to keep what I typed, even if it's a broken link.  So address books also SHOULD NOT map. 

An address book does not map: the input mechanism to the address book can map what the user typed to what is stored, and/or the display mechanism of the address book might map from what is stored to what is shown. Precision is important here.

>I could enumerate when address books should and should not map, but I really don't think we want to go there.

Then you cannot use "SHOULD" in the RFC 2119 context. So, some of "we" very much want to go there, or not use RFC 2119 language. MUST is easy, as is MAY.

>  I would much rather assume that address book developers will be able to figure out what's right. 

So, how the heck does that relate to your desire for interoperability?

>We could point out the possibilities so the developer doesn't overlook them, but we don't need to say "Do it this way." 

Ditto.

>None of us are experts in all the application types.

Fully agree. And that's why we are at this place in this discussion.