W3C

- DRAFT -

WS Description WG telcon

25 Jan 2007

See also: IRC log

Attendees

Present
Regrets
Chair
Jonathan
Scribe
tonyr

Contents


 

 

<Marsh> Tony, you there?

<Marsh> I'm worried about the reliability of my internet, and skype connection.

<Marsh> If I disappear abruptly, please keep things swimming along !

<jkaputin> Roland Merrick is actually John Kaputin (Apache Woden/IBM) standing in for Arthur Ryman

<alewis> heh. i thought roland was slumming. :-)

<Roberto> c

<scribe> scribe: tonyr

minutes approval

minutes approved without dissent

administrivia

WS-Policy responses have been accepted and applied to their spec; Charlton tracking

<alewis> i haven't seen anything, as i recall.

<Zakim> asir, you wanted to ask a question?

<alewis> grr. what happened?

MTOM description

draft of charter for the XML-P group, including MTOM

Jonathan: suggest we forward Jean-Jacques' comments on the XML-P charter to the CG and the authors of the charter

JJM: pleased that the charter is happening, but would be happier if it were more detailed

Jonathan: any specifics?
... will forward JJM's comments, but want to know if the WG has any other specific recommendations to the authors

<asir> Here is the link http://www.w3.org/Submission/2006/SUBM-WS-MTOMPolicy-20061101/

<pauld> also had a challenge when looking at the charter

<charlton> thanks asir

<pauld> http://www.w3.org/2007/01/XML-Protocol-Charter.html

jjm: could not reach the submission by clicking on the link in the charter - permissions issue

<asir> am wondering why such specific comments cannot be handled through Canon AC representative

<scribe> ACTION: Jonathan to forward comments to the author of the MTOM charter [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action01]

<scribe> ACTION: Jean-Jacques to develop more concrete suggestions for expansion of the charter for the XML-P group [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action02]

<asir> thank you for the clarification

CR112

waiting on input from Philippe - skipping

CR145

Jonathan: we agreed that the status quo is clear
... perhaps current model is unclear, and we could remove those items that are not referred to by any WSDL component

Roberto: not sure that the status quo says what you said it does

JohnK: I agree - not certain that the spec says clearly what is included

Roberto: argument detailed in e-mail is that we should only include in the component model those items which are referenceable
... those elements which are inported by things which are imported cannot be referenced unless also directly imported; only those items which are directly imported should be included

JohnK: agreed - only those items which can be referenced should be included in the component model
... Arthur had some concerns about referencability. Once we reach the component model we lose the understanding of which elements are referenceable because referenceability is a property of the document

Roberto: not sure that I agree. Yes, referenceability is a feature of the document, but if we follow the procedure I outline we will get a suitable set of components

JohnK: inclined to agree. Including everything clutters the component model with components which are not used because they were not able to be referenced
... prefer Roberto's proposal

Jonathan: like Roberto's proposal, too - it reinforces the idea of import; produces a nicer "mental model"

JohnK: we haven't covered the likely use cases - Arthur could address that if he were here
... we may need to revisit this if Arthur has additional use cases

Jonathan: are we clear on the wording we require in the spec?

<scribe> ACTION: Roberto to suggest more concrete wording for the spec for CR145 [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action03]

<Marsh> Look at sections 3.1.3 and the Desc Comp section 2.1.1

JohnK: section 3.1.3 and Description Component section in Part 1

CR117

Jonathan

Jonathan: this is about encoding the data included in a URI - what rules we should follow in determining which parts of the data are URL-encoded?
... we had two proposals:
... 1. augment the template syntax to indicate which parameters should be / should not be encoded
... 2. always encode all parameters, ensuring everything is always reversible
... in this case we'd ensure that all parameters must be separated by an unescaped character not in the set of unescaped characters

Jacek: you are talking about reconstructing the query from the URL - has this ever been an objective of the spec?

Jonathan: no, but our implementations have been requiring this ability

Youenn: yes, it makes sense to be able to reconstruct

Roberto: I like the idea of the different templating syntax. That would be a good solution, using two different serialisation "modes"
... on the other hand, I don't like the other proposal - to insist on unique deserialisation

Youenn: I think it's just a warning, not an error

Jonathan: the raw vs encoded proposal doesn't solve the real problem, which is the unique deserialisation

Jacek: I don't like the idea of adding a new feature at this time, which would require returning to LC again.
... perhaps we should add an XML simple type which disallows the set of characters which cause problems

Jonathan: can we create a simple type to do this? Right now we'd need a BNF

Youenn: the writer of the binding may not be the writer of the interface

Jacek: don't we already have this problem?
... wouldn't mind that all that much - already constrained

Jonathan: Jacek's proposal is that we add descriptive text about problems in some operations due to ambiguity from including certain characters in parameters, and provide a simple type to avoid these ambiguities
... This would not avoid the problem of reversability - will not be able to reconstruct the original query

Youenn: the server may not be able to understand the message

Jacek: The server will break? I can't see the problem here

Jonathan: unless you constrain the data in the URL, the server may be "confused"

Jacek: we have the problem already in other places - a "first name" field that could be "any string" could be sent a 5Mb string, which could cause problems with most servers

Youenn: perhaps we could insist that uncited parameters which go into the query string be encoded; cited parameters would not be encoded

Jonathan: how does that solve the problem?

Jacek: the uncited parameters would not be able to mess up the cited parameters

Jonathan: sounds like my second proposal is DOA (mandatory encoding + ban ambiguity)
... could adopt my first proposal, or Youenn's proposal

<JacekK> chad, question: CR117

<JacekK> chad, question?

<JacekK> chad, options?

<alewis> vote: 4, 3, 5, 2

<JacekK> vote: 4, 2, 0

vote: 4, 0, 5, 2, 3

<charlton> vote: 4, 5, 2, 3

<youenn> vote: 5, 1, 2, 3, 4

<Allen1> vote: 4, 0

<Roberto> vote: 1, 4, 0, 5, 3, 2

<gpilz> vote: 4, 5, 3, 2

<monica> 1,4,no others

<Jonathan> vote: 3, 5, 2

<JacekK> vote: monica: 1, 4

<jjm> vote: 5, 1, 2, 3, 4

<JacekK> chad, count

<chad> Question: CR117

<chad> Option 0: status quo (0)

<chad> Option 1: jonathat's 1st - new syntax for controlling whether or not to encode (2)

<chad> Option 2: youenn - cited parameters raw, uncited encoded (0)

<chad> Option 3: jonathat's 2nd - everything encoded, ambiguity forbidden (1)

<chad> Option 4: jacek's - all is raw, we warn people, give them guidance and maybe a restrictive simple type (6)

<chad> Option 5: everything encoded (2)

<chad> 11 voters: alewis (4,3,5,2),Allen1 (4,0),charlton (4,5,2,3),gpilz (4,5,3,2),JacekK (4,2,0),jjm (5,1,2,3,4),Jonathan (3,5,2),monica (1,4),Roberto (1,4,0,5,3,2),TonyR (4,0,5,2,3),youenn (5,1,2,3,4)

<chad> Round 1: Count of first place rankings.

<chad> Candidate 4 is elected.

<chad> Winner is option 4 - jacek's - all is raw, we warn people, give them guidance and maybe a restrictive simple type

Straw poll indicates a strong preference for Jacek's proposal

<monica> need to play lotto

<monica> $240 millon in oregon

youenn: dislike this proposal. Might be better to support the use cases we know; don't want to block future use cases

Jacek: can the use cases that this proposal blocks be addressed in the application?
... application can be built to use encoding where needed
... adding path segments is a use case which would be blocked by encoding everything

<JacekK> chad, clean

Jacek: using Youenn's proposal would still allow us to warn people of the consequences

<JacekK> chad, reset

<chad> new poll

<JacekK> chad, question: CR117

<Roberto> I prefer option 1, having authors explicitly choose between raw and encoded, over option 2

<asir> Are there any concrete proposals written down for any of these options?

Tony: concerned about security issues with RAW parameters

Jacek: have the same issues without WSDL - a user can enter a URL without using the WSDL, so there's no security hole (that wasn't already present)
... might avoid bugs / undocumented features by encoding, but nothing more

Youenn: would prefer to offer a choice of RAW/encoded

Jacek: we have a default - the status quo is that we leave everything RAW

Youenn: not sure that the default was thought through

Jacek: we are in CR - reluctant to change things at this point
... we can provide advice, and offer a simple type to avoid issues

Youenn: but there are values which won't be valid according to the simple type - some book titles won't be accepted

Jacek: if we want to put things into a URI, you have to encode them

Youenn: cannot automate the reconstruction of the query from the URL

Jacek: wonder what the web people would say about this - if we are constructing a URI, we are addressing a resource, and the resource should "know what to do"

Jonathan: there are fiddly bits in the HTTP binding. if we don't do any encoding, then there are more restrictions on the data we can use

<Roberto> if there are two classes of users with two different use cases, it makes sense to have two template syntaxes, i.e. option 1

Jonathan: guess we'll have to return this one to the mailing list. Please describe the positions clearly

<Jonathan> Thanks Tony!

Summary of Action Items

[NEW] ACTION: Jean-Jacques to develop more concrete suggestions for expansion of the charter for the XML-P group [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action02]
[NEW] ACTION: Jonathan to forward comments to the author of the MTOM charter [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action01]
[NEW] ACTION: Roberto to suggest more concrete wording for the spec for CR145 [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2007/01/25 17:34:41 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: tonyr
Inferring ScribeNick: TonyR

WARNING: No "Present: ... " found!
Possibly Present: Allen Allen1 Allen_Brookes Asir Canon Gilbert_Pilz IPcaller JJM Jacek JacekK JohnK Jonathan Marsh P0 P16 P19 P20 P22 P25 Roberto Roberto_Chinnici Roland_Merrick Tony TonyR alewis chad charlton gpilz jkaputin m2 monica pauld vote youenn youenn_
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Got date from IRC log name: 25 Jan 2007
Guessing minutes URL: http://www.w3.org/2007/01/25-ws-desc-minutes.html
People with action items: jean-jacques jonathan roberto

[End of scribe.perl diagnostic output]