Subject: [Ecrit] Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 01 Sep 2015 22:00:02 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-ecrit-additional-data-34: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Two things are incorrect and need fixing:

---- In Section 4, you have "tel" and "TYPE", and "property" and
"parameter" reversed in the explanation about the "main" parameter value.
 The sentence is also confusingly worded.  Try this (and see also my
comments on this bit, below):

NEW
   This document adds a new parameter value called "main" to the
   "TYPE" parameter of the "tel" property.
END

---- In Section 6, there are problems in the MIME structure in the
examples (figures 16 and 17).

1. The XML content should be indented at least as much as the SIP
headers, so you should either make sure that all XML lines are indented
at least 6 characters, or you should make the SIP headers be indented
only by 3.

2. There should not be a blank line between the Content-Type and
Content-Length headers.

3. There should not be a blank line after each boundary line; the part
headers should start immediately, as the first blank line ends the
headers.

4. There should be a blank line between the Content-Disposition header
and the XML content; that blank line ends the part headers and signals
the start of the part body.

5. The intermediate boundary lines should not have the trailing "--";
that's reserved for the ending boundary.  The intermediates should all be
"--boundary1".

6. Figure 17 is missing the ending boundary, "--boundary1--", at the very
end of the figure.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Throughout the document:
The current term is "media type", not "MIME type".  It would be good if
you can change that throughout the document.

-- Section 3 --
A tiny, tiny point: I don't think the MAY in the last sentence is really
a 2119 key word, and suggest making it lower case.

-- Section 4 --

   In an xCard there is no way to
   specify a "main" telephone number.  These numbers are useful to
   emergency responders who are called to a large enterprise.  This
   document adds a new property value to the "tel" property of the TYPE
   parameter called "main".

This doesn't explain sufficiently what you're after.  I initially
wondered why the PREF parameter didn't give you what you need (PREF=1,
this is my main phone number).  It was only when I read the registration
in Section 10 that I understood.  I'd suggest a value other than "main",
but I can't think of one right away.  At the least, please add more text
here to explain what you mean by "main".

I'll also note that none of the examples include the new "main" parameter
value.  Given that you're creating the value, it might be good to show it
in use.

-- Section 4.1.5 --

      The Data
      Provider Contact URI SHOULD be a TEL URI [RFC3966] in E.164 format
      fully specified with country code.  If a TEL URI is not available,
      it MAY be a generic SIP URI.

2119 key word problem @1: "you SHOULD do X, but you MAY do Y instead." 
MAY contradicts the SHOULD.  It's not so bad here because your "if"
restricts the MAY (Section 5.3 isn't that way; see below), but I'd prefer
it if you'd change it to something like "If a TEL URI is not available, a
generic SIP URI is acceptable."  Or perhaps "A generic SIP URI is
acceptable only if a TEL URI is not available," which is a little
stronger.

-- Section 4.4.2 --

      If more than one <tel> property is provided, a parameter from the
      vCard Property Value registry MUST be specified on each <tel>.

Do you really want that MUST, rather than a SHOULD?  Are you really
saying that if there are multiple phone numbers but I don't know their
TYPE values, it's better to pick one and send only that one than it is to
send you all of them just in case?

-- Section 5.1 --

   The data may also be supplied by value in any SIP request or response
   method that is permitted to contain a body (i.e., not a BYE request).

Is BYE the only SIP request that can't contain a body?  Or should that be
"e.g."?  (I'm asking; I don't know the answer.)

-- Section 5.3 --

   It is RECOMMENDED that access networks supply the data specified in
   this document by reference, but they MAY provide the data by value.

Here's the SHOULD/MAY problem without an "if" to mitigate it.  In this
case, I suggest explaining:

NEW
   It is RECOMMENDED that access networks supply the data specified in
   this document by reference.  While it's permissible to provide the
   data by value, this can expose private information [and/or whatever
   other explanation].
END

-- Section 10.1 --
Thanks for providing guidance to the expert reviewers; that's really
helpful.

-- Section 11 --
Is the comma in "Christian, Militeau" spurious?

-- Appendix A --
You appear to have turned the RELAX NG schema from RFC 6351 into an XML
schema and put it here, but then labelled it as informational -- a hedge,
I guess, in case there's a mistake in this version.  Why does it need to
be included here?  And how much review has it actually had, to make sure
that there weren't any mistakes in the conversion?

---

From: Brian Rosen <[email-masked]>
Date: Wed, 2 Sep 2015 15:17:25 -0700

I’m going to let other authors comment on the MIME stuff. 

 I’ve had a conversation with Simon Perrault who is the Expert on vCard things, and convinced him that “Main” was a reasonable addition.  I’ll give you the use case we discussed:
An employee at an enterprise places an emergency call to report a fire.  The PBX is configured to put the callers vCard on the call.  The responder needs to contact the front desk, rather than the caller.  The main number is the right way to do that.  It’s not, in any way, a “preference” value.  I can’t think of a better name that “main”.  I don’t have a problem adding more motivating text.

On the schema, we are trapped in the problem that we really need an XML schema to match what else is going on in the call data, but the vCard is Relax NG.  We provided the schema as informational for just the reason you suggest - in case of an error, it’s the Relax NG schema that is correct.  It originated with the vCard guys, we copied it, and we’ve looked at it to see that it is up to date.  

Brian

> On Sep 1, 2015, at 10:00 PM, Barry Leiba <[email-masked]> wrote:
>

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Sep 2015 22:21:12 -0400

> An employee at an enterprise places an emergency call to report a fire.
> The PBX is configured to put the callers vCard on the call.  The responder
> needs to contact the front desk, rather than the caller.  The main number
> is the right way to do that.

Yes, I understood that after reading the text in the IANA registration
section, but not after reading the text in Section 4.  That's why I
asked for more text in Section 4 explaining it.

> It’s not, in any way, a “preference” value.  I can’t think of a better name
> that “main”.  I don’t have a problem adding more motivating text.

I've asked a few other people to look at it, and they, too, didn't get
"main", but they, too, had trouble coming up with a better name.
Maybe we shouldn't try to hard to make a very short name, and use a
longer one such as "main-office", or "front-desk", or some such.  That
plus more explanation in that paragraph in Section 4 should make it
all better.

(But note, too, that this isn't a blocking comment.  I think it should
be explained better, and I'd like you to do that, but I'm not going to
hold up the document for it if you'd rather not change the name of the
parameter value.)

> On the schema, we are trapped in the problem that we really need an
> XML schema to match what else is going on in the call data, but the
> vCard is Relax NG.  We provided the schema as informational for just
> the reason you suggest - in case of an error, it’s the Relax NG schema
> that is correct.  It originated with the vCard guys, we copied it, and
> we’ve looked at it to see that it is up to date.

Ack.  That's a good enough explanation for me, and thanks.

Barry

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Sep 2015 16:11:26 -0700

>  plus more explanation in that paragraph in Section 4 should make it

I'd be happy to change the term "main" to something else, provided we 
can agree on something.  Perhaps "reception" or "main number" or 
"attendant"?  I'm kind of leaning toward "attendant" but would like 
to hear from others.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
When you are in trouble, people who call to sympathize are really
looking for he particulars.     --Edgar Watson Howe

---

From: Randall Gellens <[email-masked]>
Date: Tue, 15 Sep 2015 17:23:36 -0700

>  https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/

Thanks for catching the error and suggesting improved wording.  I've 
changed the text accordingly.

>  at least 6 characters, or you should make the SIP headers be indented

Yes, the indenting in the examples was messed up.  Thanks for 
pointing it out.  I've fixed it up (also, many of the continuation 
lines were weirdly indented, and much of the XML examples were 
inconsistently indented).

>  2. There should not be a blank line between the Content-Type and

No, there shouldn't.  Thanks for pointing it out.

>  headers should start immediately, as the first blank line ends the

Indeed.  Thanks for catching this.

>  the start of the part body.

Indeed so, thank you.

>  that's reserved for the ending boundary.  The intermediates should all be

Yes, these were sloppy errors.  Thanks for catching them.

>  6. Figure 17 is missing the ending boundary, "--boundary1--", at the very

Fixed, thanks.

Good point.  I also fixed "MIME subtype."

>  a 2119 key word, and suggest making it lower case.

Correct, either the section is normative or it isn't.  I also took 
the opportunity to clarify what is meant by "private-use".

>  here to explain what you mean by "main".

I've added text in Section 4 to help explain this: "(that is, a 
primary contact number, typically of an enterprise, as opposed to a 
direct dial number of an individual employee)".

>  value.  Given that you're creating the value, it might be good to show it

Good point.  I've fixed that.

>  acceptable only if a TEL URI is not available," which is a little

I didn't see a problem here because "SHOULD" means "do it this way 
unless there's a really good reason why you can't, and you fully 
understand the implications", while the "if ... MAY" lists one such 
really good reason.  But, I don't really care, and because you think 
it's confusing, I'm happy to change the "MAY" to "is acceptable."

>  send you all of them just in case?

Good point.  I'll switch it to a MAY.

>  "e.g."?  (I'm asking; I don't know the answer.)

Per RFC 2543:

    Requests MAY contain message bodies unless otherwise noted. Within
    this specification, the BYE request MUST NOT contain a message body.
    ...
    All
    responses MAY include a body.

So, I suppose some other RFC could define a new request that isn't 
permitted to carry a body.  I'm not sure it's worth worrying about. 
If I change it to "e.g.," that would imply that there are such 
requests now.

>     data by value, this can expose private information [and/or whatever

Good point.  I reworded it to be:

    It is RECOMMENDED that access networks supply the data specified in
    this document by reference, because PIDF-LOs can be fetched by a
    client or other entity and stored locally, so providing the data by
    value risks exposing private information to a larger audience.

>  Thanks for providing guidance to the expert reviewers; that's really

Thanks.

>  Is the comma in "Christian, Militeau" spurious?

Indeed so.  Thanks for catching that!

>  that there weren't any mistakes in the conversion?

This was discussed and resolved in separate email.

-------------- Randomly selected tag: ---------------
Scandal is gossip made tedious by morality.     --Oscar Wilde

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Sep 2015 20:38:10 -0400

Hi, Randy... thanks for resolving all this, and I think there's
nothing more that needs to be said about any of it.  Just to confirm
on a couple of them:

> I've added text in Section 4 to help explain this: "(that is, a primary
> contact number, typically of an enterprise, as opposed to a direct dial
> number of an individual employee)".

That looks great, and should be enough to explain it; thanks.

...
> So, I suppose some other RFC could define a new request that isn't permitted
> to carry a body.  I'm not sure it's worth worrying about. If I change it to
> "e.g.," that would imply that there are such requests now.

But there are none other than BYE *now*, right?  So that's fine, then:
leave it as it is, and thanks for the answer.

>    value risks exposing private information to a larger audience.

Nice.

Discuss will clear when I can check the update, and, again, thanks for
sorting it all out.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 15 Sep 2015 20:40:33 -0400

> I'd be happy to change the term "main" to something else, provided we can
> agree on something.  Perhaps "reception" or "main number" or "attendant"?
> I'm kind of leaning toward "attendant" but would like to hear from others.

"Attendant" doesn't sound great to me, but I don't object to it.  Yes,
other ideas would help, if anyone has them.

Note that this is *not* part of my DISCUSS, as you've put in
clarifying text.  So let's try to find a better term, but let's not
get *too* wrapped up in it.

Barry

---

From: Brian Rosen <[email-masked]>
Date: Wed, 16 Sep 2015 09:14:48 -0400

I would prefer “Main”.  These days, it may not answer at a reception area, and may or may not have someone called “attendant”.

Brian

> On Sep 15, 2015, at 9:21 PM, Randall Gellens <[email-masked]> wrote:
> 
> At 8:40 PM -0400 9/15/15, Barry Leiba wrote:
> 
> I'm fine with any of the ones: "reception" or "main number" or "attendant" or another one if someone comes up with it. Otherwise it'll stay "main".
> 
> 
> -- 
> Randall Gellens
> The "press conference" is a politician's way of being informative
> without saying anything. Should he accidentally say something, he
> has at his side a "press officer" who immediately explains it away
> by "clarifying" it.                               -- Emery Kellen

---

From: Matt Serra <[email-masked]>
Date: Wed, 16 Sep 2015 15:31:54 +0000

An alternative more generic name for TYPE could be "preferred" or "primary" or something to describe that this is the first number they should try to call from amongst other contact info provided in the xCARD.

This may better convey what we are trying to distinguish, and work for a broader set of non-office environments, so long as folks feel it is not too redundant with "PREF" (I'm not sure how well implemented PREF is, so we may not be able to count on it being used extensively)

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Tuesday, September 15, 2015 7:11 PM
To: Barry Leiba; Brian Rosen
Cc: [email-masked]; [email-masked]; [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)")

At 10:21 PM -0400 9/2/15, Barry Leiba wrote:

>  I've asked a few other people to look at it, and they, too, didn't 
> get  "main", but they, too, had trouble coming up with a better name.

I'd be happy to change the term "main" to something else, provided we can agree on something.  Perhaps "reception" or "main number" or "attendant"?  I'm kind of leaning toward "attendant" but would like to hear from others.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- When you are in trouble, people who call to sympathize are really
looking for he particulars.     --Edgar Watson Howe

---

From: Matt Serra <[email-masked]>
Date: Wed, 16 Sep 2015 18:19:23 +0000

I'm fine with "main-number"

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2015 12:16 PM
To: Matt Serra; Randall Gellens; Barry Leiba; Brian Rosen
Cc: [email-masked]; [email-masked]; [email-masked]; The IESG; [email-masked]; [email-masked]
Subject: RE: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)")

My concern is that "preferred" is too generic and doesn't convey the sense of a main number for an organization.  I realize there are often automated attendants, but still think "attendant" would cover most cases.  However, how about using "main-number"?

At 3:31 PM +0000 9/16/15, Matt Serra wrote:

>  An alternative more generic name for TYPE could be "preferred" or 
> "primary" or something to describe that this is the first number they 
> should try to call from amongst other contact info provided in the 
> xCARD.
>
>  This may better convey what we are trying to distinguish, and work 
> for a broader set of non-office environments, so long as folks feel it 
> is not too redundant with "PREF" (I'm not sure how well implemented 
> PREF is, so we may not be able to count on it being used extensively)
>
>  Cc: [email-masked]; [email-masked]; 
> [email-masked]; The IESG; 
> [email-masked];
> [email-masked]
>  Subject: [Ecrit] New term for "main" (was "Re: Barry Leiba's Discuss 
> on draft-ietf-ecrit-additional-data-34: (with DISCUSS and
> COMMENT)")
>
>> longer one such as "main-office", or "front-desk", or some such.  
>> That  plus more explanation in that paragraph in Section 4 should 
>> make it  all better.
>
> "attendant"?  I'm kind of leaning toward "attendant" but would like to 
> hear from others.
>
>  --
>  Randall Gellens
>  -------------- Randomly selected tag: --------------- When you are in 
> trouble, people who call to sympathize are really

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- XML is crap. Really. There are no excuses. XML is nasty to parse for humans, and it's a disaster to parse even for computers. There's just no reason for that horrible crap to exist.  --Linus Torvalds, March 6, 2014