Hi, Peter.
That's mostly fine. A few bits of remaining suggestions below...
BTW It appears that Scott Brim drew the lot on reviewing 3921bis.. if
you think it would help I could negotiate with him to do 3921 as well.
I expect you will be glad to get these out the door (and maybe before
Christmas!)
Regards,
Elwyn
On Tue, 2010-12-14 at 05:49 -0700, Peter Saint-Andre wrote:
> Would you perhaps have a chance to look at this before the IESG telechat
> on Thursday?
>
> On 12/10/10 2:53 PM, Peter Saint-Andre wrote:
> > Hi Elwyn,
> >
> > Thanks for your reply. Unfortunately I got impatient and submitted a
> > revised I-D earlier today (-20), but I can always submit another one if
> > needed. Version numbers are cheap. :)
> >
> > Comments inline.
> >
> > On 12/10/10 11:18 AM, Elwyn Davies wrote:
> >>
> >> Hi, Peter.
> >>
> >> Sorry I was not responsive on checking your quick reponses here. Have
> >> been rather tied up with a draft I am authoring (and have the editor's
> >> pencil for at the moment).
> >>
> >> A few points from reviewing the diff you pointed to - it is mostly an
> >> excellent update:
> >> 4.7.1.. use MAY about 'from' rather than SHOULD? Does the note apply
> >> only to connected clients only? There is a MUST for servers. Section
> >> 4.8.3's comments on jabber-client vs jabber-server may be relevant.
> >
> > Do you mean this note?
> >
> > Security Warning: Notwithstanding the recommendations in the
> > remainder of this section, the initiating entity SHOULD NOT
> > include a 'from' address on the initial stream header it sends
> > before the confidentiality and integrity of the stream are
> > protected via TLS or an equivalent security layer (such as the
> > SASL GSSAPI mechanism), since doing so would expose the initiating
> > entity's identity to eavesdroppers.
> >
> > I think that applies to both servers and clients, if they care to
> > protect their identity from casual eavesdroppers on the very first
> > stream header (before TLS or similar protection)
The wording in this section is still slightly confusing because of the
apparently conflicting SHOULD NOTs in the note and the later
SHOULD/MUST. I was running on the lines that the SHOULD NOT only
affected the client-server case, but that is clearly not what is
intended. Perhaps the thing to do is to add an additional sentence to
the Note: 'The requirements for inclusion of 'from' addresses in the
rest of this section apply to cases where a security layer is not used
and to the stream headers used when restarting the stream after the
security layer has been negotiated.'
> >
> >> 4.9.1.1: Should the shall in the last sentence be SHALL?
> >
> > I have tried to use no lowercase instances of the capitalized keywords,
> > but missed that one. Fixed.
> >
> >> 5.2 SHOULD -> RECOMMENDED if available but not mandatory-to-negotiate.
> >
> > Don't SHOULD and RECOMMENDED mean the same thing?
> >
> > RFC 2119 says:
> >
> > ###
> >
> > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> > may exist valid reasons in particular circumstances to ignore a
> > particular item, but the full implications must be understood and
> > carefully weighed before choosing a different course.
> >
> > ###
It's a long time since I read RFC 2119 :-(
I was thinking of the subtle distinction in common usage between should,
which in my book implies a degree of obligation greater than
recommended. Given 2119 I guess it makes no difference which one you
use.
> >
> >> 13.9.1: Base64 -> Base 64 in the section title.
> >
> > I tried to make our terminology consistent with RFC 4648, but missed the
> > title (and one instance in Section 6.5.5). Fixed.
> >
> >> 14.x: email addresses x...@ietf.org -> i...@ietf.org
> >
> > Fixed.
> >
> >> In line comments about changes..
<snipped the pieces where we have agreement>
> >> A few notes on the SHOULDS (-19 section numbers) - omitted ones seem
> >> fine:
> >>
> >> s3.2.3: This SHOULD is a policy/implementation issue. It doesn't affect
> >> protocol implementation SHOULD -> should or ought to.
> >
> > Sure. I don't think folks are too strict about conformance terms in
> > relation to implementation decisions, but I suppose you're right in this
> > case. Changed to "is encouraged to"...
> >
Fine.
>
> >> s3.3: I'd go for MUST in both cases.. don't you get beaten up about
> >> congestion otherwise?
> >
> > I don't think this rises to the level of an absolute commandment. It's
> > network-friendly, but nothing breaks absolutely if it's not followed.
> >
The transport area tend to get riled about things that might cause
congestion.. but if they aren't complaining I suppose its OK.
> >> s4.6.4, last para: The first strikes me as a MUST (although there is the
> >> obvious get out if the receiver's default is what the initiator
> >> specifies). There seems to be a not-very-subtle bug in the generated
> >> text bit.. If the receiver doesn't support the initiator's default
> >> language then putting the initiator's specified language on to a
> >> generated message that isn't in that language ('cos the receiver doesn't
> >> do it) sounds rather stupid.
> >
> > It's not the intended recipient that we're talking about here, it's the
> > routing server. If I tell my server that my preferred language is
> > 'de-CH' but it can't send me error messages (etc.) in 'de-CH', it can
> > still stamp my outbound stanzas with 'de-CH' on my behalf.
That case is clear. After careful reading I got the impression that if
the server itself sent messages (such as relating to the account) that
were locally generated by the server and sent them back to the client
then it was obliged to mark them with the client's preferred language
even if this made no sense 'cos the server couldn't handle the preferred
language. Maybe this is a non-existent case.
> >
> >> s4.6.5, item 3: .. and close the stream. I guess the receiver might
> >> want to log why it didn't succeed.
> >
> > A stream error is always followed by a stream close (Section 4.9.1.1),
> > so I don't see a reason to add those four words here.
Sorry - I missed the the s4.9.1.1 requirement.
> >
> > However, I've added pointers to the specific sections for each error
> > condition whenever they are mentioned, and fixed up a few other places
> > where we followed "send a stream error" with "and close the stream".
Fine.
> >
> >> s4.6.5, item 4: Do typical legacy servers barf or ignore if they get a
> >> version attribute? If barf, then maybe it should be MUST.
> >
> > Those would be rather old legacy servers now (pre-2004), and as far as I
> > know they ignore the 'version' attribute (I think we would have known
> > about it by now if they barfed).
OK - leave it as it is.
> >
> >> s5.2: SHOULD -> HIGHLY RECOMMENDED
> >
> > there is no HIGHLY RECOMMENDED in RFC 2119. :) I think "SHOULD" is fine.
OK. Same point as before on SHOULD/RECOMMENDED.
> >
> >> s5.4.3.3, item 5: discussed below.
> >>
> >> s8.2.1: Isn't this a 'will contain a 'to' except if it is going to the
> >> connexted client's account on the server'?
> >
> > Sure. Changed to:
> >
> > The <message/> stanza is a "push" mechanism whereby one entity pushes
> > information to another entity, similar to the communications that
> > occur in a system such as email. All message stanzas will possess a
> > 'to' attribute that specifies the intended recipient of the message
> > (see Section 8.1.1 and Section 10.3), unless the message is being
> > sent to the bare JID of a connected client's account. Upon receiving
> > a message stanza with a 'to' address, a server SHOULD attempt to
> > route or deliver it to the intended recipient (see Section 10 for
> > general routing and delivery rules related to XML stanzas).
Good.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
