See also: IRC log
<Yves> http://www.w3.org/2006/09/27-xmlprotocol-minutes.html
minutes approved
possibly cancel next week's call
pete, chris and anish will be at the WS-I plenary
will defer decision until the end of the call
all actions complete
discussion of whether to reference 3986 or 3987
noah: I think that there are some chars that
can be used in IRI that would be disallowed in URI
... xs:anyURI has always been an IRI compatible type
... probably need to figure out which things are URI and which IRI
yves: strange thing in schema part 2 they are referencing 2386
also an old ID for IRI
noah: schema 1.1 draft?
yves: yes ED oct 6
<Yves> http://www.w3.org/XML/Group/2004/06/xmlschema-2/datatypes.html
noah: looking at older WD from feb 2006
<noah> 3.3.18 anyURI
<noah> [Definition:] anyURI represents an Internationalized Resource Identifier Reference (IRI). An anyURI value can be absolute or relative, and may have an optional fragment identifier (i.e., it may be an IRI Reference). This type should be used when the value fulfills the role of an IRI, as defined in [RFC 3987] or its successor(s) in the IETF Standards Track.
yves: just looking at reference section
<noah> From Oct. 6 Schema 1.1 editor
<noah> editor's draft
noah: editors simply haven't cleaned up
references section
... clearly the reference for IRI in xs:anyURI is normative
chris: two paths... choose 3987 and figure out which are URI and which IRI or just reference 3986 and change references see if anyone complains
noah: would have thought that the only thing we would need to do is look for particular references to 2396 and see if the majority just turned 3986
<Yves> http://www.w3.org/2000/xp/Group/6/09/PER/soap12-part1.html
<Yves> look for [3986] references
<Yves> http://www.w3.org/2000/xp/Group/6/09/PER/soap12-part1.html#useofuris
<Yves> XML Base refers to RFC 2396
noah: think that going to IRI is an
incompatible on the wire thing
... are soap engines checking this? I doubt it
... the schema implies it is an xs:anyURI and that may be a little looser
than we had intended
<Yves> http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2005Mar/0047
noah: suggests some text for section 6
pete: problem might be in string comparison
noah: we are normatively URI based... we could say by the way, if you have an IRI, here is how we recommend you send it (encoded)
<noah> Proposed to put in chapter 6, probably after the first paragraph:
<noah> Where this specification calls for a URI, the string supplied MUST conform to the URI syntax [detailed ref needed] from RFC 3986. Note: RFC 3987 provides means by which Internationalized Resource Identifiers, IRIs, can be encoded into corresponding URIs.
<noah> It is recommended that such encodings be used to encode IRIs for use as URIs with SOAP. The XML Protocols workgroup may, in some future release, provide for the direct use of IRI's in some or all of the cases where URIs are now required.
10[15:43] noah: 01Proposed to put in chapter 6, probably after the first paragraph:
10[15:43] noah: 01Where this specification calls for a URI, the string supplied MUST conform to the syntax [detailed ref needed] from RFC 3986. Note: RFC 3987 provides means by which Internationalized Resource Identifiers, IRIs, can be encoded into corresponding URIs.
10[15:43] noah: 01It is recommended that such encodings be used to encode IRIs for use as URIs with SOAP. The XML Protocols workgroup may, in some future release, provide for the direct use of IRI's in some or all of the cases where URIs are now required.
10[15:44] noah: 01s/conform to the syntax/conform to the URI syntax/
10[15:43] noah: 01Proposed to put in chapter 6, probably after the first paragraph:
10[15:43] noah: 01Where this specification calls for a URI, the string supplied MUST conform to the syntax [detailed ref needed] from RFC 3986. Note: RFC 3987 provides means by which Internationalized Resource Identifiers, IRIs, can be encoded into corresponding URIs.
10[15:43] noah: 01It is recommended that such encodings be used to encode IRIs for use as URIs with SOAP. The XML Protocols workgroup may, in some future version, provide for the direct use of IRI's in some or all of the cases where URIs are now required.
10[15:44] noah: 01s/conform to the syntax/conform to the URI syntax/
dhull: we only talk about uris as markers as opposed to addresses on the web
noah: we walk both sides of the line... it does
identify a resource
... this is not a release in which we are introducing breaking changes
dhull: yep
... fine with the text
<scribe> ACTION: editors to incorporate noah's proposed text above [recorded in http://www.w3.org/2006/10/11-xmlprotocol-minutes.html#action01]
RESOLUTION: Noah's text adopted to be appended to section 6 SOAP 1.2 part 1
add non-normative ref to 3987
chris: are we okay to proceed with publication of PER
yves: rasied issue re: XML1.1 informal reference
noah: we had a long discussion about this and
decided against
... any binding can use what it wants on the wire
... also application/soap+xml not sure if that is limited to xml1.0
yves: it is
noah: as long as we don't lead people to think that they can use 1.1 where they may not
<Yves> [[ A SOAP message is specified as an XML Information Set [XML Information Set (Second Edition)]. While all SOAP message examples in this document are shown using XML 1.0 [Extensible Markup Language (XML) 1.0 (Fourth Edition)] syntax, other representations
<Yves> MAY be used to transmit SOAP messages between nodes (see 4. SOAP Protocol Binding Framework).
<Yves> ]]
chris: okay with adding, only concerned that someone might ask why the informal reference is included but not referenced
pete: ambivalent, no effect on spec
yves: if some uncomfortable, then I could live without the ref
dave: fine either way
chris: do nothing, can we declare victory?
all: yes
chris: no change, no ref to xml1.1
... everyone okay with proceeding with pub req?
all: yes
RESOLUTION: proceed with PER pub req
http://lists.w3.org/Archives/Public/xml-dist-app/2006Sep/0021.html
noah: neither of us agree on our respective first choice, we could live with the third
but it is our least preferred
chris: the third option is one that I had originally opposed, but if it resolves the stalemate, then maybe that is the thing to do... more work, but not that muc more
noah: apealing aspect of option 3 is it says precisely what multicast does
<Yves> my preference goes to be as silent as possible in multicast
yves: because we are using intermediaries, my
preference is that we be silent on the use of multicast
... oneway mep should be silent on that
<noah> Actually, I said that the appealing aspect of option 3 is that it allows each binding to clearly indicate, through its choice of MEP, whether it does or does not provide a multicast service. It preserves a clean binding for what I view as the core case, which is unicast-only.
<noah> I don't think we can be entirely silent. We have to either say it's one message to one destination, or we have to say something more general.
dhull: reviews some history
<Yves> yes, and the fact that the "one destination" is a multicast address is beyond the scope of the MEP
<Yves> and using a one way MEP when multicast is meant, well, is dangerous, as using GET to buy a book ;)
noah: could you elaborate, yves?
yves: concerned about HTTP intermediaries
noah: MEP is most concerned with how many times
SOAP processing is involved
... intermediary would not be implenting MEP because it is not a soap node
dhull: you can have multiple SOAP nodes running off a single physical message
chris: yves, you have preference for option 1
yves: yes
dhull: surprised that no one has asked what the
resulting bindings look like, think we should have a pretty good answer for
what a binding looks like
... I asked yves what the email binding looked like in response to his
point
noah: udp binding to option 1 is pretty straight forward
<Yves> email binding looks like req/0+ responses MEP, and this MEP is not defined (yet)
dhull: but you'd have to stipulate you couldn't use a broadcast address
chris: have seen papers that describe HTTP over multicast
noah: views the constraint on the addess as a modest complication
dhull: this is as much discussion on this topic that I have seen in past two months
noah: most of my thought are captured in the note
should "poll" WG on where they stand
chris: pete, do you have a position?
pete: need to talk to people back at the office
<scribe> ACTION: chris to re-stimulate the thread with noah/david's note [recorded in http://www.w3.org/2006/10/11-xmlprotocol-minutes.html#action02]
<dhull> Adding "you can't use a UDP broadcast address" doesn't complicate the spec greatly. It does potentially complicate its use. In the case of email, it complicates use of the spec greatly, as far as I can tell.
<dhull> I.e. "With email, your message may be received by 0..N receivers" seems much simpler (in spec and use) than "You MUST use a system that only allows single recipients, or make sure your to: address is just one receiver, and ensure that there are not multiple SOAP nodes listening there, and ..."
chris: since we haven't resolved, we WILL have a call next week to continue the discussion while we have all the players available
adjourned