Vojtech: This happens in two parts, both when you're constructing a request and when you're processing a response.

16:08:04 [Norm]

We got your voicemail henry!

16:08:14 [ht]

Sorry, hang on

16:08:34 [ht]

zakim, please disconnect ht

16:08:34 [Zakim]

Ht is being disconnected

16:08:36 [Zakim]

-Ht

16:09:09 [ht]

zakim, please call ht-781

16:09:09 [Zakim]

ok, ht; the call is being made

16:09:10 [Zakim]

+Ht

16:09:17 [Norm]

Nope, ht, try again!

16:09:20 [ht]

zakim, please disconnect ht

16:09:20 [Zakim]

Ht is being disconnected

16:09:21 [Zakim]

-Ht

16:09:52 [ht]

zakim, please call ht-781

16:09:52 [Zakim]

ok, ht; the call is being made

16:09:53 [Zakim]

+Ht

16:10:43 [Norm]

Present: Norm, Paul, Vojtech, Alex, Mohamed, Henry

16:11:12 [Norm]

Some discussion

16:11:58 [Norm]

Alex: This is more complicated becuase there can be encodings and such in the header value.

16:12:10 [Norm]

Vojtech: Right. Do we ignore one, or merge them which would be too complicated, or what?

16:12:46 [Norm]

Alex: We do have encoding, and encoding is going to effect the content types of each of the bodies sent. So you should have a charset parameter on the content types.

16:13:47 [Norm]

...And if you specify a different charaset parameter explicitly, then that can be a problem too.

16:14:32 [Norm]

Alex: I think the right way to look at this is that the computed values should match.

16:15:10 [Norm]

...We need to reword XC0020 to cover that case.

16:16:05 [Norm]

Norm: Two things: one is the logic for computing the content type, the other is what to do with the header values.

16:17:45 [Norm]

Alex: I think it's a potentially slippery slope, there are lots of things in HTTP that can be confusing.

16:18:13 [Norm]

Norm: Alex, can you take a stab at some prose to discuss this?

16:18:18 [Norm]

Alex: Absolutely.

16:18:30 [Norm]

ACTION: Alex to describe how content type values are computed.

16:19:59 [Norm]

Norm: For the error, I thought I heard that if you specify both content-type on the body and an explicit c:header for the Content-Type header, then the computed value MUST exactly match the specified c:header value, or that's an error.

16:21:00 [Norm]

Alex: Yes.

16:21:14 [Norm]

Accepted.

16:21:33 [Norm]

ACTION: Norm to add text about the error case after we have wording from Alex

16:22:11 [Norm]

Topic: 090 p:hash and xml:base

16:22:28 [Norm]

Norm: I couldn't find it in the minutes, but I think we decided to allow it, even if it's probably stupid.

16:22:30 [Norm]

Vojtech: Right.

16:22:36 [Norm]

Accepted.

16:23:00 [Norm]

Topic: 091: duplication of information in c:multipart

16:24:26 [Norm]

Some discussion

16:25:10 [Norm]

Norm: Vojtech: you can do it any way. If you specify the multipart in the pipeline you can do this.

16:25:37 [Norm]

Alex: This is about the request, yes?

16:25:50 [Norm]

Vojtech: I think it's about both.

16:26:47 [Norm]

Alex: If you put a content-type attribute in there with a boundary parameter and specify a boundary, then that's going to be a conflict. I think we should say the same thing we said for 089 about computed values.

16:27:53 [Norm]

Norm: We could also say that the content-type attribute should be the bare value without parameters.

16:29:54 [Norm]

Some more discussion about the value of the boundary attribute.

16:31:17 [Norm]

Alex: The boundary attribute is required. Eew.

16:31:43 [Norm]

Norm: I think removing it would force us back to Last Call.

16:32:35 [Norm]

Alex: So we can just say they have to be the same, and use XC0020.

16:32:40 [Norm]

Norm: Why not forbid it?

16:32:47 [Norm]

Alex: Because of the round-tripping case.

16:34:27 [Norm]

Norm: So the proposal I hear is that we say that if you specify them both, they MUST match.

16:35:16 [Norm]

Accepted.

16:35:40 [Norm]

Vojtech: So the remainder of the question, when you parse the response, do you generate the headers?

16:36:19 [Norm]

...I think you do generate them, but the values will always match so it's ok.

16:36:25 [Norm]

Norm: Yes, I think you generate the headers.

16:37:00 [Norm]

Topic: 092: p:http-request error content

16:37:24 [Norm]

Alex: This one is easy, you get back the content. 404 is just like any other response.

16:37:26 [Norm]

Norm: Yep.

16:37:29 [Norm]

Vojtech: I think so too.

16:37:38 [Norm]

Proposal: Close w/o action.

16:37:47 [Norm]

Accepted.

16:38:00 [Norm]

Topic: 093: p:http-request: status message

16:38:20 [Norm]

Alex: That seems like a nice to have.

16:39:04 [Norm]

...I don't think it's something we need to do for V1.

16:39:35 [Norm]

Proposal: Not in V1.

16:39:43 [Norm]

Accepted.

16:39:58 [Norm]

Topic: 094: p:http-request content-type and encoding

16:41:22 [Norm]

Alex: Right now you get an error. The encoding parameter on p:http-request applies to all of the parts.

16:43:11 [Norm]

Some discussion

16:47:11 [Norm]

Henry observes that we can say "don't do this". The only way you could get here is fi you had two documents and wanted to encode them differently.

16:47:26 [Norm]

Alex: Does the encoding serialization parameter apply to non-XML content.

16:48:15 [Norm]

Some argument about whether or not you can have non-XML *to* seralize.

16:48:21 [Norm]

s/seralize/serialize/

16:50:08 [Norm]

Henry: We don't have to support this and I don't think that's a problem.

16:51:26 [Norm]

Alex: If I have a c:body element with a content-type of text/plain and I have the word XProc in there and that's it and I don't specify any options, I'm going to get an error.

16:51:59 [Norm]

...I'm going to run XML serialization on the text string XProc and the serialization code is going to have a fit becuase I didn't set a method.

16:54:47 [Norm]

Vojtech: We say that the serialization options are provided to control serialization of any XML content.

16:56:32 [Norm]

ACTION: Norm to fix the content model of c:body as it's reproduced in the spec

16:56:54 [Norm]

Alex: I think we still don't have the content type handling correct here.

16:58:28 [Norm]

Henry: There's no paragraph that specifies what happens if the content type does not specify an XML media type.

16:59:08 [Norm]

Henry: What I said before was wrong, XML serialization is never involved if the content type isn't an XML media type.

17:00:07 [Norm]

...We say the output will consist of "those characters" but what we have to put on the wire is "those bytes"