Subject: [sipcore] #43: Small fixes

From: "sipcore issue tracker" <[email-masked]>
Date: Fri, 17 Sep 2010 17:35:31 -0000

#43: Small fixes
---------------------------------+------------------------------------------
 Reporter:  worley@…             |       Owner:     
     Type:  defect               |      Status:  new
 Priority:  minor                |   Milestone:     
Component:  rfc4244bis           |     Version:     
 Severity:  In WG Last Call      |    Keywords:     
---------------------------------+------------------------------------------
 This ticket is a collection of items that are either editorial nits
 (things that an editor might correct) or "minor" wording improvements
 (things that require content knowledge to fix but seem to have no
 interesting/controversial technical content).  Several of these have
 been consolidated from previous tickets (as noted).

 --- Ticket #30

 Stray double-quote:

     History-Info is a header field as defined by [RFC3261]. "It may

 Missing space:

     is set to a value of "mp".The "mp" attribute in the hi-target

 --- Ticket #33

 I see the sentence "The following summarizes the syntax..." -- this
 suggests that the actual syntax definition/specification is
 elsewhere. Do you mean "The following is the syntax..."?

 --- Ticket #31

 In section 6.1 is:

     The following rules apply:

     o There MUST be exactly one hi-index parameter per hi-entry.

     o There MUST be no more than one hi-target parameter.

     o There MAY be any number of hi-extension parameters.

     o The ABNF definitions for "generic-param" and "name-addr" are
     from [RFC3261].

 The fourth item is different from the first three and should be put
 elsewhere.

 The second and third items also need "... per hi-entry". But since
 that would apply that qualifier to all 3 of the remaining items in the
 list, it would be better to phrase it:

     The following rules apply to each hi-entry:

     o There MUST be exactly one hi-index parameter.

     o There MUST be no more than one hi-target parameter.

     o There MAY be any number of hi-extension parameters.

 --- Ticket #36

 Section 6.3.1 para 1 starts:

     This specification defines a new SIP/SIPS URI Parameter indicating
     the mechanism by which a new target for a request is determined.

 However the actual name of the parameter is not given until para 5. I
 suggest putting the name of the parameter into the first sentence of
 para 1.

 --- Ticket #39

 Section 6.3.1 para 5 is:

     The following defines the ABNF for the "hit" URI parameter:

 Please change this to:

     The ABNF for the "hit" URI parameter is:

 (The object of "define" is always a word or term that is defined; it
 is not the ABNF that is defined. Indeed, the ABNF *defines* the
 syntax of the "hit" URI parameter.)

 --- Ticket #17

 In section 3 is the odd phrase "any valid response" -- are there
 invalid responses? What is validity of responses? Better would be "any
 response", or probably more informatively, "any provisional or final
 response".

 --- Ticket #26

 In section 5.2 is "SHOULD forward captured History-Info in subsequent,
 provisional, and final responses to the request". I think that
 "subsequent" adds no meaning and should be removed.

 --- Ticket #22

 This:

     A UAC that does not want an hi-entry added due to privacy
     considerations MUST include a Privacy header with a priv-value(s)
     of "header" or "history." A UAC that wants to ensure that privacy
     not be applied to its identity MUST include a Privacy header with
     a priv- value of "none."

 should have the punctuation moved for clarity:

     A UAC that does not want an hi-entry added due to privacy
     considerations MUST include a Privacy header with a priv-value(s)
     of "header" or "history". A UAC that wants to ensure that privacy
     not be applied to its identity MUST include a Privacy header with
     a priv-value of "none".

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/43>
sipcore <http://tools.ietf.org/sipcore/>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 17 Sep 2010 16:38:13 -0400

(as chair *and* participant)

I'm *really* not liking the way the issue tracker works - that the mail 
subject doesn't say what draft the issue relates to.

What do other people think about that?

Is anybody an expert on the tracker? Is there some way to configure it 
to put the component name into the subject line?

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Sat, 18 Sep 2010 14:31:13 -0500

I agree. I think we should put together some basic guidelines and put
on the SIPCORE tools wiki. In my opinion, the value of the tracker is
in documenting real technical issues so that they don't get lost in
email threads and the resolution is clearly documented and is readily
available. It is more overhead than it is worth in my opinion for
editorial/nits/typos unless there is lack of clarity in the text.

For example, here's a few guidelines I would suggest:

1) The title should have the full draft name so it appears in the
email Subject. I think the version number is important in particular
if folks might not have read the most recent version OR in the case
where new issues arise in subsequent versions while there might still
be issues in a previous version. Also, I think the document section
number should be in the title - that makes it a whole lot easier when
trying to develop changes that address all the issues in a particular
section.
2)  Only real technical issues should have a separate issue number. It
would be good for folks to review previous issues before entering new
ones and add comments to those that are related rather than opening a
new issue.
3) Pure editorial nits (e.g., insert space between end of one sentence
and next sentence)  do NOT need to be entered into the tracker - just
send an email to the author/editor.
4) Editorial comments (e.g., re-arranging paragraphs, suggested word
changes) should be gathered into a single issue.  Personally, I do not
think folks should be so very concerned about applying grammatical
corrections to the document UNLESS there is lack of clarity or overt
errors.  The RFC editor already has their view of grammatical style
and they will normalize the text if necessary - in the end, they could
well revert what someone might suggest to what the author originally
had.  In my experience, no matter how much work you think you've done
handling these sorts of things, the RFC editor will always find more.

Regards,
Mary.

On Fri, Sep 17, 2010 at 3:38 PM, Paul Kyzivat <[email-masked]> wrote:
> Is anybody an expert on the tracker? Is there some way to configure it to
> put the component name into the subject line?
>
>        Thanks,
>        Paul
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 19 Sep 2010 18:24:05 -0400

These sound like reasonable suggestions to me, to the extent that they 
are implementable. Its not clear to me that there is that much control 
over what goes in the subject line of the emails.

	Thanks,
	Paul

On 9/18/2010 3:31 PM, Mary Barnes wrote:
> On Fri, Sep 17, 2010 at 3:38 PM, Paul Kyzivat<[email-masked]>  wrote:

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Sep 2010 18:43:29 +0200

Another aspect of etiquette is how you make a comment on a tracker issue. You have two choices:
- add a comment to the tracker (thereby causing the tracker to generate the email);
- regular email (e.g., in response to the tracker-generated mail when the issue was logged), making sure the ticket number and other relevant information appears in the subject line, of course.

The first option is not always so use friendly in my opinion, because it sends out only the new comment, not the background or any previous comment. So the poor reader has to go find the ticket on the tracker to get the whole thread, or go searching for all previous emails with the ticket number concerned.

The second option allows you to include the original problem or earlier comment, with interleaving if required. On the other hand it can lead to very long emails.

In general I prefer the first option, i.e., just use the tracker when you want to change status.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 19 September 2010 23:24
> To: Mary Barnes
> Cc: [email-masked]; [email-masked]
> Subject: [sipcore] Tracker usage policies
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 30 Sep 2010 17:59:01 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Elwell, John [[email-masked]]

IMHO, the question is not so much one of user friendliness as one of the nature of the comment.  If you are contributing to an ongoing discussion, i.e., "We could use method A, or we could use method B, or maybe method C.", one wants to circulate it quickly to lots of people, but the message has no permanent significance.  On the other hand, if the comment is a revision or extension to the tracker issue's problem statement, or a pointer to an important external resource, then it should be a tracker comment.  In a sense, the question is, "If someone needs to research this matter three months from now, would he need to read this comment?"

Dale