Re: Web Services Addressing 1.0 Core comments

David, thanx for the quick response.

>> 2.1 [address] is defined as an IRI but the description contains 
"...this
>> URI is used...".  Shouldn't that says "...this IRI is used...]?  This
>> happens in a few other places.  The editors should carefully check all
>> uses of URI to insure that they shouldn't actually be IRI.
> 
> This usage is deliberate.  If something meets the tighter 
> constraints of URI, we say "URI", otherwise we say "IRI".  So for 
> example [address] is an IRI, but the anonymous address in particular
> is a URI and we say so.  It would also be correct to say " ... this 
> IRI is used ..." but we discussed the issue and opted for the present 
wording.

I understand this rationale...but in that case I think it would be good to 
put something in the "Notational Conventions" section explaining this...so 
that other readers don't have to wonder.

>> 3 "The contract between the interacting parties may specify that 
multiple
>> or even a variable number of replies be delivered" should be "The 
contract
>> between the interacting parties MAY specify that multiple or even a
>> variable number of replies be delivered."  The editors should check all
>> uses of "conformance verbs", to make sure they are capitalized
>> appropriately.

> In other words, the classic RFC 2119 MAY means "One vendor may 
> choose to include the item because a particular marketplace requires
> it or because the vendor feels that it enhances the product while 
> another vendor may omit the same item."  Here we're saying that 
> different interactions may define various rules and the presence of 
> "ReplyTo" doesn't necessarily mandate use of a particular definition
> of "Request-Response".

By "capitalized appropriately" I meant that they should be ALL CAPS when 
they have conformance strength and not caps when they don't.  I was rushed 
when doing my review and wasn't sure in what sense these were being used 
in this context.  Upon further reading, I think both occurances of 'may' 
in this paragraph do NOT have conformance implications for implementors of 
THIS spec...so they are OK not capitalized.  I still request that the 
editors do a double-check to make sure that those that do have 
implications for implementors of THIS spec are ALL CAPS.

> 3.1 [reference params] I'm sure there's a good reason but why isn't
> [destination] and EPR?  The presence of [ref params] (and it's 
description
> as applying to [destination] )would seem to indicate that [dest] really 
is
> an EPR and not "just" an IRI.  Is the current model because of 
difficulty
> binding "to" EPRs to common transports?  I realize it is VERY late in 
the
> process to change something this fundimental but it has always seemed 
odd
> to me...sorry for not saying anything sooner.
> 
> Heh.  There is a formal objection around just this issue, but for 
> better or worse, [destination] is an IRI.

I'm glad I'm not to only one to feel that there is something wrong.

> 3.2  section 3.4 describes the default for wsa:FaultTo as being
> wsa:ReplyTo..and if wsa:ReplyTo is empty then it's a free-for-all. 
> Shouldn't this behavior be stated here?  since the defaults of all the
> other properties are described here.
> 
> Again, this is deliberate (originally the description was in section
> 3.2).  This section defines the semantics of [reply endpoint] and 
> [fault endpoint] in the context of request-response.  Other patterns
> may define other semantics.  These shouldn't be gratuitously 
> different from what we give here, but they may have to be different 
> in various ways.  Perhaps there is a good reason [fault endpoint] 
> shouldn't default to [reply endpoint], but both designations 
> otherwise make sense. We did not want to prohibit that.

I think it is fine to have it in 3.4...I guess I was just asking for a 
"forward pointer" in 3.2.

> 3.2.1 why isn't comparison of [source], [reply endpoint] and [fault
> endpoint] discussed?
> 
> This, too, is deliberate.  There are thorny issues involved in 
> defining the context within which a particular comparison is 
> meaningful.  Byte-for-byte identical EPRs may mean different things 
> depending on context, and completely different-looking EPRs may mean
> the same thing.  Rather than try to define what an EPR "means", we 
> define what you can do with it.

It would help me (and I think others) if you included something similar to 
the above paragraph so that readers don't have to stop and ask "hey, they 
talk about comparison of *those*, why aren't they talking about 
comparision of *these*?"

Again, all of HL7's comments are basically editorial in nature (wsa:To as 
an EPR is a little stronger than editoral :-) and so any resolution you 
come up with is fine.  We are looking forward to WS-Addr becoming a Rec 
because we have are developing a standard that relies on it and we can't 
progress that one until WS-Addr becomes a Rec.

pvb