W3C

XML Protocol WG
11 Oct 2006

Agenda

See also: IRC log

Attendees

Present
Pete Wenzell, Chris Ferris, Noah Mendelsohn, David Hull, Yves Lafon
Regrets
Chair
Chris Ferris
Scribe
Chris Ferris

Contents


 

 

<Yves> http://www.w3.org/2006/09/27-xmlprotocol-minutes.html

minutes approved

administrative

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

action item review

all actions complete

status of PER

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

multicast

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

Summary of Action Items

[NEW] 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]
[NEW] ACTION: editors to incorporate noah's proposed text above [recorded in http://www.w3.org/2006/10/11-xmlprotocol-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/10/12 10:00:41 $