W3C XML Protocol Working Group teleconference, 19 June 2002

1. Roll

Present 30/25 Excused Regrets Absent

2. Agenda review


	

3. The WG approved the XMLP WG minutes from its 12 June 2002 telcon,

without objection.

        

4. Action items


* Ed: Pending
* MB: Has been Superseeded. Leave that action alone (DF)
* NM: Done
* Ed: Done
* Ed: Done
* DF: Done
* NM: Done
* Ed: Done
* Ni : Done
* DF: Done
* HN : Done
* AK : Done
* DF: Done
* DF :Done
* YL : Done
* DF : Done
* Ed: Done
* YL : Almost done. Leave it pending.

Paul : Unlisted action item. Taking all the LC issues to a e-mail. Haven't
seen any e-mail from you.
DF: All the comments are embodied in LC announce e-mail. An updated version
was sent out this morning. That update incorporates comments made by you &
Noah.

        

5. Resolution of TAG mime finding


DF: We have a internet draft describing the media type. We sent the first
version to IETF which is listed in our Web page. On another thread we were
in the process of making a IANA application for the "application/soap+xml"
media type which refers the internet-draft. Our original approach was to
update the internet-draft and reference that in our IANA application.

In the mean time, TAG found an issue with that approach. Their concern is
that the internet draft doc doesn't live as part of a W3C spec. I have
spoken with several people on TAG and out-of TAG about what would satisfy
their
concern.

Current thinking is we should take the content from the internet-draft and
make it a normative appendix in part II of our spec. We would then refer to
that appendix in our IANA application. There are some issues with that,
e.g. making such a reference is not a well-trodden path on registering
media type. W3C understands that. W3C is interested in making that process
work and action is already taken with IANA to see whather that would work.

Alternatively, we stay with our original approach and refer to that content
in the internet-draft.

DO: I want to reinforce the fact that TAG is very aware and understanding
of the WG's schedule constraints.  How do you perceive this separation
between TAG and IANA?

DF: WRT what TAG wants, I do not know what TAG really wants because I
haven't recd any formal communication on that though I have spoken to
various members. I do get a different story from different TAG members.

PC: Which TAG member gives a a diff story?

DF: For example, Tim Berners-Lee.

DO : As an XMLP WG member, I wish to understand what TAG is saying is
different from what TBL is saying?  I need to know if there is a
difference.

DF: TBL said, ideal thing is to put the internet draft into appendix. Dan
Connolly also said that. TAG has described various courses of action
ranging from this ideal to other choices. So, we are left with a choice on
how to proceed. Opinions vary on how we are going achieve that.

It appears there are 2 options.

Option 1: Take the content of the internet draft and make it a normative
appendix of part II. Make some update to the status section and to the LC
Announce e-mail, and make a note of the uncertainity involved here.

Option 2: Submit the IANA application with the internet-draft and add to
the LC e-mail that we are seeking feedback of the review of the
internet-draft at the same level as the rest of the spec.

HN: Agrees with option 1. The draft is very small and there are already
lots of things we refer to which are not part of the spec. The only thing
that may be different in this case is that the action parameter is specific
to SOAP.

DF: Maybe a question to TAG on the reason for closer proximity to media
type registration???

PC: If there is anything in the internet draft and not in the spec, TAG
members are not comfortable with that. Both the director and some TAG
members think that is dangerous and bad.

HN: In general that is true but here that is very specific to the MIME
media type and not a SOAP specific thing and so not the same case. It is
just a question of having another link. But, we should make it reviewable
and call
for review.

PC: My point is that there is something in the registration but not in the
spec.

NM: On one hand taking option 1 makes the spec standalone. On the other,
specification such as XML reference other (Unicode) documents. I see this
one as in the grey area. Henrik sees media type stands on its own with a
pretty
thin encapsulation. Even if we copy it, it probably won't stand on its own.
On the other hand spec standing on its own is not bad either.

PC: No not my opinion but just repeating others opinions.

DO: Do you believe that is the consensus of the TAG?

PC: Director has to approve LC. I asked Tim, whether you would approve the
LC if MIME registration is not in the spec. Tim said he won't.

DF: Question to Editiors. How long would it take to incorportae MB's text
(i.e. the internet draft) and make an appendix and put some text into the
status section?

HN: There are 2 levels. Moving the action thing is 1 day. Moving the whole
is a little longer.

MB: We need to be sensitive to IANA's need to locate that information they
are looking for

DF: Are we saying that to ensure no-redundancy takes 1 day?

HN : Cut and paste of the Action parameter is 1 day. Moving the whole thing
and ensuring no redundance is more than 1 day. Agree with MarkB.

MB: Okay with option 1 or option 2.  Remove redudancy. Have a form usable
by IANA. I do think it is better to put the form for IANA in the spec.

DF: We do not have a lot of time. We are risking the LC review period.

MB: Just go ahead with internet-draft and fold it in later. I don't think
we should register with IANA now.

HN: In order to register it requires IESG review and I don't think we can
do that.

MB: I think such review is not always required but also we are dealing with
IANA not IETF

DF: Isn't the text going to be redundant if it is in the spec?

MB: IANA doesn't have change control. It is with IETF.

SW: There appear to be 3 artefcats, (i) registration form, (ii) spec, (iii)
RFC. Registration form references RFC.
IANA says to register we need to have RFC. There are a quite number of
registrations that are not RFC docs. The registration form could refer to a
W3C spec rather than a RFC.

MB: Typically RFC is the registration form or includes the registration
form. We could refer to our spec in that. Question is whether IANA and IETF
would be happy with that?

HN: option 2 is less risky.

SW: option 2 is what XMLP WG originally planned.

DF: With option 2 we are 'back-loading' the work. We don't have touch the
current text. It requires some extra text in the e-mail. Some other
shell-rfc text. Is the objection against option 1 that it is going to take
1 or 2
days or a significant additional amount of time? Is that right?

Working Group: Yes.

SW: with option 2 we could be signalling to move the text into PR. That
might help Tim.

DF: Yes. we could add something to add to the status text about that
possibility.

MB: Prefers option 1.

HN & PC and many others prefer option 2.

DF: we will do option 2.

In the LC e-mail we will ask for review of the media type document. We will
also modify the status section in the spec to state our intent that we will
be bringing the internet-draft material into the spec as a normative
appendix at a later date.

MB: my preference for option 1 is that it explictly asks for that review.
With option 2, we should ask for a specific review and for inconsistencies.

DF: My second version of LC e-mail already takes that into account.

PC: Status section of part 2 only needs to be modified.

DF: What is the status of the internet-draft?

MB: It is in w3.org and I don't have access to change but will likely have
more changes. I will work with HFN.

DF: we have a dependency here so we need to get the modification done
before referencing. How long will it take?

MB: Tonight. HFN agrees to help out.

DF: Will we submit as an update to the internet draft. What about IANA?

HN: We don't go to IANA now. We will go once we have IESG review. 4 weeks
review time. After that we will have a RFC number and then we can go the
IANA.

DF: What will the reference in the spec point to?

HN: Best to point to the updated internet-draft.

DF: could we point to a document on the W3C site?

HN: We could do that. We could do a redirect from W3C to IETF as well.

DF: Should we send an e-mail to TAG telling them what we are going to do?

PC: Yes, and it is a good thing to send that email before Thursday to get
it onto the TAG agenda.


        

6. Document issues


Noah has raised 2 issues.

First issue is about references between the media-type draft and the spec.
Largely in agreement with the note HN sent. Fundamentally we should be
clear on what the HTTP binding should send. That has turned into a IETF
draft now. It sort of says, "use XML 1.0 serialization". Section 5
contradicts a little bit. It is basically about how do you recognize a SOAP
message once you see it. (NM reads from the e-mail he sent out "SOAP 1.2
does not require or assume that SOAP 1.2 messages have any particular
serialization, making it impossible to determine {in the absence of other
information} when a chunk of data is a SOAP 1.2 message or not. However,
for the case of the XML 1.0 serialization of SOAP 1.2 messages, the
following best describes how these messages may be recognized.")

I think this can be resolved by clarifying the section 5 text. We should
make crisp and clear that one should use XML 1.0 serialization when
application/soap+xml media type is used.

HN: Agrees with that.

NM: I am OK to leave it to MB or HN to make that clarification.

DF: Any objections?

DF: No objections. So, we should handle that as part of the other effort.

NM: Associated with the first issue is something related to UTF 8 & UTF 16.
My previous understanding from the spec was that all SOAP processors must
recognize UTF 8 and UTF 16 and they can recogonize others as well. Now I am
unsure.

DF: What are we saying about this? Is it clear that the SOAP processer must
recognize UTF 8 and UTF 16.

HN & MB believe it does so.

DF: Let us get going. That can be handled by MB in his update.

Second Noah issue: Deals with 'deprecated' in primer.

NM: Sam Ruby was very concerned about deprecating POST for information
retrieval. Primer says that this is a deprecated way of doing it. I am
okay, but this is causing some concerns in the SOAP circles.

My proposed resolution requires changes in two places. Instead of saying
deprecated say 'this representation is encouraged' . The second thing is to
mention  that not all retrievals are safe. ( Noah goes on to give some
examples. Not captured here. They include examples like audit trail etc).
Also make a not even if retrieval is safe SOAP features can be used only if
used POST as it requires a Envelope.

DF: How long would it take to make these changes? (to Nilo)

Nilo: I can do it today.

DF to the WG: shall we do this?

MH: First part of the proposal is ok but the second part of the issue goes further.. particularly
talking about audit trails etc.... Most Web servers keep logs and can still
do a safe side-effect free retrieval. So that should not be considered.

DF: Can we just change the header caption and leave the rest for LC?

No objections raised, many voices of agreement.

DF: OK, so it is decided that we will change only the header caption. We
have finished the agenda. There are a couple more issues. One is the
publication timetable. A second is to reaffirm whether we go to LC on
account of the changes we have made recently.

PC: Do you want to step through the points made in my e-mail that responded
to your LC Announce draft?

DF: OK, we'll do that briefly and then go back to the timetable and
reaffirmation.

PC: If we are going to quote something in the documents it should perfectly
match the documents themselves. The TC collection doesn't have a test for
each assertion.

DF: The final wording in the Announce email will be copied from the final
docs. The "for each" assertion will be fixed in the final wording.

PC: The wording on transitioing from PR to CR not possible. Just stop with
PR (ie. If these criteria are met, the specification will advance to
Proposed Recommendation). If implementation requirements are not met it
will enter CR.

DF: OK.

PC: The proposed text says no-one has filed patents, but some of the patent
disclosures are pretty strong statatements to me.

DF: Two points, one is I copied out of charter, and secondly no-one has
explicitly identified any patents.

PC: But the text doesn't say that. I have made my point; it is your
decision.

DF: We have a web page of all the IPRs and we can reference that.

PC: As stated in point 5 of my email, that reference should appear in the
spec's status section. It is incomplete if a status section doesn't point
to that. List IPRs and provide a link.

PC: (On point 4 in his e-mail) No where in the LC we say where to send the
implementation experience. We have  already talked about having a web page.
There are 2 parts. A place to send a e-mail. And then a web page.

DF: We have a web page listing implementations. Good catch on the other
point, I'll add a "mail-to" address for implementation experience.

AK: About the word 'each' in the Test Collection document.

PC: If it is in the doc it should be removed.

DF: No objections. Anish remove each.

AK: There are 2 more changes, should I do them?

DF: No, unless very critical. If not critical we shouldn't consider.

AK: The changes relate to spec text. 2 spec text changes are not reflected
in the test document.

DF: What is severity of the errors?

AK: Asir pointed out one change is important but the other is not.

AK: I don't think we need to remove the tests. Just to copy and change the
text.

DF: go ahead and change the text then.

YL: Assertions 91 issue should go away.

DF: We can change spec text. Anything more let us do it during LC.

AK: Lynne is right. Asir also agrees.

DF: Removing at this time is risky. We can do it during LC.

PC: I say ship what we have. Send comments to about the assertions to
xmlp_comments. That way public will be aware of that.

DF: Good suggestion.

LT: May lead to some confusion with regard assertion 91.

AK: No test removal. Just assertion.

DF: There are no objections by the WG to leave it as it is. So, only change
allowed is 'each'. We have to move along now. Summary of timetable:
- All changes by tonight.
- DF will do the LC announce e-mail changes.
- Spec status changes will be done by DF.
- Will tell Yves that we are ready to go.
- Yves will do that as soon as he has all the materials. Tomorrow morning?
- By sometome tomorrow the request would have been sent.

DF: Last question. Last week we decided to go to Last Call. Since then we
have made a number of changes and so I am going to ask agaian whether there
are now any objections to requesting LC?

No objections raised.

DF: The WG has affirmed its decision to go to LC.

Applause!!!!!!!!!!!

PC: Thanks David.

NM: Are we ready for our F2F, e.g. should I buy plane tickets now or
hold-off?

DF: Still depends a little bit on when the specs actually get published -
hopefully early next week. So I suggest waiting until then.